How to programmatically list all transitive dependencies, including overridden ones in Maven using DependencyGraphBuilder? - maven

This is similar to other questions (like this), but I want to be able to do this with the latest API's. The maven-dependency-plugin:tree verbose option has been deprecated and does nothing in the latest (2.5.1) code, so there is no good example of how to do it.

I believe Aether utility class from jcabi-aether can help you to get a list of all dependencies of any Maven artifact, for example:
File repo = this.session.getLocalRepository().getBasedir();
Collection<Artifact> deps = new Aether(this.getProject(), repo).resolve(
new DefaultArtifact("junit", "junit-dep", "", "jar", "4.10"),
JavaScopes.RUNTIME
);
If you're outside of Maven plugin:
File repo = new File("/tmp/local-repository");
MavenProject project = new MavenProject();
project.setRemoteProjectRepositories(
Arrays.asList(
new RemoteRepository(
"maven-central",
"default",
"http://repo1.maven.org/maven2/"
)
)
);
Collection<Artifact> deps = new Aether(project, repo).resolve(
new DefaultArtifact("junit", "junit-dep", "", "jar", "4.10"),
"runtime"
);
The only dependency you need is:
<dependency>
<groupId>com.jcabi</groupId>
<artifactId>jcabi-aether</artifactId>
<version>0.7.5</version>
</dependency>

Including my approach here, as the additional steps may become part of your actual use case, esp. if working on a composite or multi-module project.
(Maven 3, my runtime was 3.6; no direct dependency on Aether)
In my case I wanted to resolve the dependency tree of a specific artifact foo-runtime from inside my plugin; however,
some of the dependency versions were only available in its parent's foo-parent POM (i.e. absent in the foo-runtime's own POM).
The parent POM also had additional details, such as exclusions for some of foo-runtime's dependencies - via dependencyManagement.
So I had to:
explicitly load the parent's model,
link the child model to it,
fill in the missing version numbers of the child model (still not sure why Maven didn't automatically resolve these after linking the parent), and then
run dependency resolution for the child.
To avoid model building from scratch, I derived the model of of foo-runtime using an existing artifact foo-api (which in my case is always guaranteed to be present in the Maven project being built). All these artifacts share the same groupId.
#Component
public LifecycleDependencyResolver resolver;
// ...
// `artifacts` contains all artifacts of current/reactor `MavenProject` obtained via `project.getArtifacts()`
private Set<Artifact> resolveRuntimeDeps(Set<Artifact> artifacts) throws MojoExecutionException {
// foo-api will always be present; use it to derive coordinates for foo-runtime
Artifact fooApi = artifacts.stream().filter(artifact -> "foo-api".equals(artifact.getArtifactId()))
.findFirst().orElseThrow(() -> new MojoExecutionException("Unable to find foo-api"));
Collection<String> scopes = Arrays.asList("compile", "runtime");
MavenProject fooRoot = deriveProject(fooApi, "foo-parent");
Model fooRootPom = fooRoot.getModel();
MavenProject fooSrv = deriveProject(fooApi, "foo-runtime");
fooSrv.setParent(fooRoot);
// some foo-runtime deps depend on versions declared on parent pom; merge them
Map<String, Artifact> depMgt = fooRootPom.getDependencyManagement().getDependencies().stream()
.collect(Collectors.toMap(dep -> dep.getGroupId() + ":" + dep.getArtifactId() + ":" + dep.getType(), this::toArtifact));
for (Dependency d : fooSrv.getDependencies()) {
if (d.getVersion() == null) {
Artifact managed = depMgt.get(d.getGroupId() + ":" + d.getArtifactId() + ":" + d.getType());
if (managed != null) {
d.setVersion(managed.getVersion());
}
}
}
try {
resolver.resolveProjectDependencies(fooSrv, scopes, scopes, session, false, Collections.emptySet());
return fooSrv.getArtifacts();
} catch (LifecycleExecutionException e) {
throw new MojoExecutionException("Error resolving foo-runtime dependencies", e);
}
}
// load POM for another artifact based on foo-api JAR available in current project
private MavenProject deriveProject(Artifact fooApi, String artifactId) throws MojoExecutionException {
Model pom;
String pomPath = fooApi.getFile().getAbsolutePath().replaceAll("foo-api", artifactId).replaceAll("\\.jar$", ".pom");
try (InputStream fooRootPomData = new FileInputStream(pomPath)) {
pom = new MavenXpp3Reader().read(fooRootPomData);
pom.setPomFile(new File(pomPath));
} catch (IOException | XmlPullParserException e) {
throw new MojoExecutionException("Error loading " + artifactId + " metadata", e);
}
// set these params to avoid skips/errors during resolution
MavenProject proj = new MavenProject(pom);
proj.setArtifact(toArtifact(pom));
proj.setArtifactFilter(Objects::nonNull);
proj.setRemoteArtifactRepositories(Collections.emptyList());
return proj;
}
private Artifact toArtifact(Model model) {
return new DefaultArtifact(
Optional.ofNullable(model.getGroupId()).orElseGet(() -> model.getParent().getGroupId()), model.getArtifactId(),
Optional.ofNullable(model.getVersion()).orElseGet(() -> model.getParent().getVersion()), "compile", model.getPackaging(), null,
project.getArtifact().getArtifactHandler());
}
private Artifact toArtifact(Dependency dep) {
return new DefaultArtifact(dep.getGroupId(), dep.getArtifactId(), dep.getVersion(), dep.getScope(), dep.getType(), dep.getClassifier(),
project.getArtifact().getArtifactHandler());
}
(I tried almost all the other suggested approaches, however all of them ended up with some error or another. Now, looking back, I suspect many of those errors might have been due to the fact that my leaf POM was missing version numbers for some artifacts. It seems (acceptably so) the "model enrichment" phase - propagating parent versions etc. - is carried out by some earlier component in Maven's flow; and the caller has to take care of this, at least partially, when invoking the dependency resolver from scratch.)

Related

Creating RepositorySystemSession using Aether

I'm trying to get all transitive dependencies of a maven project in a List of Artifacts.
I found the documentation of Aether with some example code to set up the process. One part of it is the RepositorySystem.
private static RepositorySystem newRepositorySystem() {
DefaultServiceLocator locator = MavenRepositorySystemUtils.newServiceLocator();
locator.addService(RepositoryConnectorFactory.class, BasicRepositoryConnectorFactory.class);
locator.addService(TransporterFactory.class, FileTransporterFactory.class);
locator.addService(TransporterFactory.class, HttpTransporterFactory.class);
return locator.getService(RepositorySystem.class);
}
But I get a NullPointerException in the return value.
I have no idea why?
Big thanks

How to update the <latest> tag in maven-metadata-local when installing an artifact?

In the project I am working on we have various multi-module projects being developed in parallel, some of which are dependent on others. Because of this we are using using version ranges, e.g. [0.0.1,), for our internal dependencies during development so that we can always work against the latest snapshot versions. (I understand that this isn't considered best practice, but for now at least we are stuck with the current project structure.) We have build profiles set up so that when we perform a release all the version ranges get replaced with RELEASE to compile against the latest released version.
We have to use ranges as opposed to LATEST because when installing an artifact locally, the <latest> tag inside maven-metadata-local.xml is never updated, and so specifying LATEST will get the last version deployed to our Artifactory server. The problem with the ranges though is that the build process seems to have to download all the metadata files for all the versions of an artifact to be able to determine the latest version. As our project goes on we are accumulating more and more versions and artifacts so our builds are taking longer and longer. Specifying LATEST avoids this but means that changes from local artifact installs are generally not picked up.
Is there any way to get the <latest> tag in the maven-metadata-local.xml file to be updated when installing an artifact locally?
If you are working with SNAPSHOT's you don't need version ranges apart from that never use version ranges (only in extrem rare situtions). With version ranges your build is not reproducible which should be avoided in my opinion under any circumstance.
But you can use things like this:
<version>[1.2.3,)</version
but as you already realized that caused some problems, but I would suggest to use the versions-maven-plugin as an alternative to update the projects pom files accordingly.
mvn clean versions:use-latest-versions scm:checkin deploy -Dmessage="update versions" -DperformRelease=true
This can be handled by CI solution like Jenkins. But I got the impression that you are doing some basic things wrong. In particular if you need to use version ranges.
I had the same problem, so I wrote a maven plugin to handle it for me. It's a pretty extreme workaround, but it does work.
The documentation for creating maven plugins is on The Apache Maven Project. You could just create a plugin project from the command line archetype and add this mojo to your project.
/**
* Inserts a "latest" block into the maven-metadata-local.xml in the user's local
* repository using the currently configured version number.
*
* #version Sep 23, 2013
*/
#Mojo( name = "latest-version", defaultPhase = LifecyclePhase.INSTALL )
public class InstallLatestVersionMojo extends AbstractMojo {
/**
* Location of the .m2 directory
*/
#Parameter( defaultValue = "/${user.home}/.m2/repository", property = "outputDir", required = true )
private File repositoryLocation;
#Parameter( defaultValue = "${project.groupId}", property = "groupId", required = true )
private String groupId;
#Parameter( defaultValue = "${project.artifactId}", property = "artifactId", required = true )
private String artifactId;
/**
* Version to use as the installed version
*/
#Parameter( defaultValue = "${project.version}", property = "version", required = true )
private String version;
public void execute() throws MojoExecutionException, MojoFailureException {
try {
// Fetch the xml file to edit from the user's repository for the project
File installDirectory = getInstallDirectory(repositoryLocation, groupId, artifactId);
File xmlFile = new File(installDirectory, "maven-metadata-local.xml");
Document xml = getXmlDoc(xmlFile);
if (xml != null) {
// Fetch the <latest> node
Node nodeLatest = getNode(xml, "/metadata/versioning/latest");
if (nodeLatest == null) {
// If <latest> does not yet exist, insert it into the <versioning> block before <versions>
nodeLatest = xml.createElement("latest");
Node versioningNode = getNode(xml, "/metadata/versioning");
if (versioningNode != null) {
versioningNode.insertBefore(nodeLatest, getNode(xml, "metadata/versioning/versions"));
}
}
// set the version on the <latest> node to the newly installed version
nodeLatest.setTextContent(version);
// save the xml
save(xmlFile, xml);
}
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
private void save(File xmlFile, Document xml) throws TransformerFactoryConfigurationError, TransformerException {
Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.setOutputProperty(OutputKeys.INDENT, "yes");
Result output = new StreamResult(xmlFile);
Source input = new DOMSource(xml);
transformer.transform(input, output);
}
private Node getNode(Document source, String path) throws XPathExpressionException{
Node ret = null;
XPathExpression xPath = getPath(path);
NodeList nodes = (NodeList) xPath.evaluate(source, XPathConstants.NODESET);
if(nodes.getLength() > 0 ) {
ret = nodes.item(0);
}
return ret;
}
private XPathExpression getPath(String path) throws XPathExpressionException{
XPath xpath = XPathFactory.newInstance().newXPath();
return xpath.compile(path);
}
private File getInstallDirectory(File repositoryLocation, String groupId, String artifactId) {
String group = groupId.replace('.', '/');
return new File(repositoryLocation, group + "/" + artifactId);
}
private Document getXmlDoc(File xmlFile) throws ParserConfigurationException, SAXException, IOException {
DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
return dBuilder.parse(xmlFile);
}
}
How about defining those internal dependencies as modules in one reactor pom? That way you'll compile against the compiled sources (in target/classes) instead of against a jar, and you'll always have the latest code.

maven install became very slow after using "LATEST" and "RELEASE" version

i'm using maven 2.2.1 in my daily work. recently i found my "maven install" become quite slow (about 3 times slower).
after doing many compile and debug, i found that its the lots of RELEASE and LATEST version dependencies(which were used to be specific numbers) that handicap the compile progress.
i know that "RELEASE" and "LATEST" are both deprecated functions in maven, and should not be used any more. but as adopting "RELEASE" and "LATEST" are something that i cannot change in my job. i can only try some luck with the code. and here they are:
public class DefaultMavenProjectBuilder extends AbstractLogEnabled
implements MavenProjectBuilder, Initializable, Contextualizable
{
private Map processedProjectCache = new HashMap();
public MavenProject buildFromRepository( Artifact artifact,...) {
String cacheKey = createCacheKey( artifact.getGroupId(), artifact.getArtifactId(), artifact.getVersion() ); // <========= the "get key"
MavenProject project = (MavenProject) processedProjectCache.get( cacheKey );
if ( project != null )
{
return project;
}
Model model = findModelFromRepository( artifact, remoteArtifactRepositories, localRepository, allowStubModel );
ProjectBuilderConfiguration config = new DefaultProjectBuilderConfiguration().setLocalRepository( localRepository );
MavenProject mavenProject = buildInternal("Artifact [" + artifact + "]", model, config, remoteArtifactRepositories,
null, false);
return mavenProject;
}
private MavenProject buildInternal(String pomLocation,
Model model,
ProjectBuilderConfiguration config,
List parentSearchRepositories,
File projectDescriptor,
boolean strict, String cacheKey)
throws ProjectBuildingException
{
//...
cacheKey = createCacheKey( project.getGroupId(), project.getArtifactId(), project.getVersion() ); // <========= the "set key"
processedProjectCache.put( cacheKey, project );
//...
}
}
i found that the main reason is buildInternal() been invoked 10 times more than before. and what caused that is, "set key" and "get key" became different, for example:
set key: com.foo:bar:RELEASE
get key: com.foo:bar:1.0.11
my plan is pass the "get key" into buildInternal, and used directly as the "set key", but not sure this won't break other things...
are there any suggestions?
thanks in advance :)

convertopom task in Ivy. How to add more artifacts to publications field

When I use convertpom task in Ivy to convert a pom.xml to ivy.xml, I get default publications
<publications>
<artifact name="XYZ" type="jar" ext="jar" conf="master"/>
</publications>
How do I modify pom.xml, so that more artifacts are added to this in conversion. Where does converttopom pick up the artifacts from. Also, how do I change the type?
Is it possible to override these in ivy:publish call?
found this piece of code in convertpom ant task, not sure how it is used.
private void addSourcesAndJavadocArtifactsIfPresent(
PomModuleDescriptorBuilder mdBuilder, ParserSettings ivySettings) {
if (mdBuilder.getMainArtifact() == null) {
// no main artifact in pom, we don't need to search for meta artifacts
return;
}
ModuleDescriptor md = mdBuilder.getModuleDescriptor();
ModuleRevisionId mrid = md.getModuleRevisionId();
DependencyResolver resolver = ivySettings.getResolver(
mrid);
if (resolver == null) {
Message.debug("no resolver found for " + mrid
+ ": no source or javadoc artifact lookup");
} else {
ArtifactOrigin mainArtifact = resolver.locate(mdBuilder.getMainArtifact());
if (!ArtifactOrigin.isUnknown(mainArtifact)) {
String mainArtifactLocation = mainArtifact.getLocation();
ArtifactOrigin sourceArtifact = resolver.locate(mdBuilder.getSourceArtifact());
if (!ArtifactOrigin.isUnknown(sourceArtifact)
&& !sourceArtifact.getLocation().equals(mainArtifactLocation)) {
Message.debug("source artifact found for " + mrid);
mdBuilder.addSourceArtifact();
} else {
// it seems that sometimes the 'src' classifier is used instead of 'sources'
// Cfr. IVY-1138
ArtifactOrigin srcArtifact = resolver.locate(mdBuilder.getSrcArtifact());
if (!ArtifactOrigin.isUnknown(srcArtifact)
&& !srcArtifact.getLocation().equals(mainArtifactLocation)) {
Message.debug("source artifact found for " + mrid);
mdBuilder.addSrcArtifact();
} else {
Message.debug("no source artifact found for " + mrid);
}
}
ArtifactOrigin javadocArtifact = resolver.locate(mdBuilder.getJavadocArtifact());
if (!ArtifactOrigin.isUnknown(javadocArtifact)
&& !javadocArtifact.getLocation().equals(mainArtifactLocation)) {
Message.debug("javadoc artifact found for " + mrid);
mdBuilder.addJavadocArtifact();
} else {
Message.debug("no javadoc artifact found for " + mrid);
}
}
}
}
This really demonstrates one of the key differences between Maven and ivy...
An ivy file explicitly lists all the files contained in the module. A Maven POM on the other hand does not. Instead zero or more additional files can be stored in Maven each with a different "classifier" to make the filename unique.
I can't see any way to build the complete "publications" section in ivy without having access to the Maven module's filesystem. Are you using a Maven repository manager? Nexus has a REST API that perhaps you could invoke to obtain all files in a module (Just a thought)
Another idea is to submit a request to extend the convertpom task. Create some optional child tags that enable you to list the available classifiers:
<ivy:convertpom pomFile="pom.xml" ivyFile="ivy.xml">
<classifier name="sources"/>
<classifier name="javadoc"/>
<classifier name="archive" type="tar.gz/>
</ivy:convertpom>
I don't see this change being very popular (or useful). Most people are converting in the other direction using the makepom task.

Maven plugin artifact filter unimportant dependencies

I'm developing a Maven plugin and using the MavenProject object to access my dependencies with project.getDependencyArtifacts(), but this gives my all jar, even the test only jars.
Is there some method to filter all non runtime jar? If I just get the scope and compare for scope.equals("runtime") I will throw out the compile and other important dependencies.
I did not find an existing method for this either so I'm using the following logic. This is a plugin building a customized ear, which adds the needed dependencies to an xml file and include them in the archive. It is using getArtifacts instead of getDependencyArtifacts since I'm also interested in transitive dependencies.
Collection<Artifact> dependencies = new ArrayList<Artifact>();
dependencies.addAll(project.getArtifacts());
for (Iterator<Artifact> it=dependencies.iterator(); it.hasNext(); ) {
Artifact dependency = it.next();
String scope = dependency.getScope();
String type = dependency.getType();
if (dependency.isOptional() || !"jar".equals(type) || "provided".equals(scope) || "test".equals(scope) || "system".equals(scope)) {
getLog().debug("Pruning dependency " + dependency);
it.remove();
}
}

Resources