search

qaware / go-offline-maven-plugin

Maven Plugin used to download all Dependencies and Plugins required in a Maven build, so the build can be run without an internet connection afterwards.
Apache License 2.0
162 stars 15 forks source link

Multi-module build failure #16

Closed rnc closed 4 years ago

rnc commented 4 years ago

I am seeing failures like:

[ERROR] Error downloading dependencies for project
[ERROR] The following artifacts could not be resolved: org.commonjava.maven.ext:pom-manipulation-cli:jar:minimal:3.9-SNAPSHOT, org.commonjava.maven.ext:pom-manipulation-io:jar:tests:3.9-SNAPSHOT, org.commonjava.maven.ext:pom-manipulation-core:jar:tests:3.9-SNAPSHOT: Could not find artifact org.commonjava.maven.ext:pom-manipulation-cli:jar:minimal:3.9-SNAPSHOT

from running

mvn -Dmaven.repo.local=/tmp/repo de.qaware.maven:go-offline-maven-plugin:1.2.3:resolve-dependencies

with Maven 3.6.2. I am using repository https://github.com/release-engineering/pom-manipulation-ext with SHA db3be6d3668250e9f72be0b45c1f0e67f0fd936e on branch master.

Theoderich commented 4 years ago

Thank you for the report. The problem seems to be that some reactor projects output multiple artifacts with different classifiers, but the go-offline-plugin only recognises the main artifact as a "reactor artifact". Could be tricky to resolve. I am looking into it.

rnc commented 4 years ago

@Theoderich I haven't tried it but could getAttachedArtifacts be used to compute what is in the reactor?

Theoderich commented 4 years ago

getAttachedArtifacts unfortunately does not output the correct information since the attached artifacts are only added when the custom maven-jar-plugin execution runs...

I have pushed a new version to the master branch that should fix the problem by no longer taking type and classifier into consideration when determining if an artifact is part of the reactor build. I think it is fair to assume that all artifacts with the same groupId:artifactId:version identifier are created by the same maven project.

Can you build an test the new version of the plugin to confirm that it works for you?

rnc commented 4 years ago

@Theoderich Nice! That works. However I think have found another problem. I had to add some error logging in https://github.com/qaware/go-offline-maven-plugin/blob/master/src/main/java/de/qaware/maven/plugin/offline/DependencyDownloader.java#L211 (to get the stack trace), but once I had done that I found (using the same example above):

org.eclipse.aether.collection.DependencyCollectionException: Failed to collect dependencies at org.jboss.da:reports-model:jar:1.7.0
.....
Caused by: org.apache.maven.model.resolution.UnresolvableModelException: Failure to find org.jboss.bom:jboss-eap-javaee7-with-tools:pom:7.1.2.GA in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced

Now, while org.jboss.bom:jboss-eap-javaee7-with-tools:pom:7.1.2.GA is not in central, that referring pom does have a parent that has a repositories section (https://github.com/project-ncl/dependency-analysis/blob/1.7.0/pom.xml#L296) that gives the correct repository. At a guess - is the resolver configured to use repositories (and for repositories found in the inheritance? )

Theoderich commented 4 years ago

So we have a dependency (org.jboss.da:reports-model) that has a parent (org.jboss.da:parent) that has a dependency (org.jboss.bom:jboss-eap-javaee7-with-tools) that is not in maven central. But org.jboss.da:parent defines that repository. Phew!

The go-offline plugin does take repostories into account, but not those of external dependencies. But indeed mvn install resolves those dependencies correctly. Looking into it

rnc commented 4 years ago

@Theoderich Phew indeed! Hopefully my explanation made sense :-D As https://github.com/release-engineering/pom-manipulation-ext is public it should be possible to reproduce locally.

Theoderich commented 4 years ago

That was easier than expected! The flag "IgnoreArtifactDescriptorRepositories" was actually hard set to "true" by the plugin instead of using the value provided by maven. At the time I thought that would be the correct behaviour, but as your example demonstrates maven actually does use repositories from dependencies. So using the maven provided value for "IgnoreArtifactDescriptorRepositories" should be the right thing to do.

Please test if the new push fixes the issue on your side :)

rnc commented 4 years ago

Perfect! That does fix it :-) Nice!

Theoderich commented 4 years ago

I'll do some testing and release the new version 1.2.4. Thanks for your report :)

Theoderich commented 4 years ago

1.2.4 is released on maven central