[
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873630#comment-15873630
]
Mark Raynsford commented on MASSEMBLY-848:
------------------------------------------
The problem is here (this entire method, really):
https://github.com/apache/maven-plugins/blob/trunk/maven-assembly-plugin/src/main/java/org/apache/maven/plugins/assembly/artifact/DefaultDependencyResolver.java#L232
I'm debugging based on the contents of an integration test, the
original source files of which came from this example project:
https://github.com/io7m/independent-versioning-20170207
When line 232 is reached in the debugger, the dependencyArtifacts
parameter contains the two artifacts
com.io7m.experimental:mod-a:jar:1.1.0:compile and
com.io7m.experimental:mod-b:jar:1.2.0:compile and both of those claim
to already have been resolved (isResolved() == true), which makes sense
as they're reactor projects. Both are present in the given
configSource.reactorProjects list. However, the code doesn't appear to
make any use of this list or the fact that the artifacts are already
resolved. It simply passes the list of artifacts to the resolver which
then fails with an OverConstrainedVersionException because the reactor
project artifacts aren't in any of the remote or local repositories.
This seems to be the root cause, but I can't work out
whether this is expected behaviour, misuse of an API, an oversight, or
possibly all or none of the above!
> Version range dependencies not resolved from the reactor
> --------------------------------------------------------
>
> Key: MASSEMBLY-848
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-848
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9
> (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00)
> Maven home: /opt/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix"
> Reporter: Mark Raynsford
> Attachments: mvn.log.gz
>
>
> When using modules that have independent version numbers (that is, modules in
> the same project may have different version numbers), it's commonplace to
> specify dependencies between modules with version ranges when using semantic
> versioning.
> For some reason, when version ranges are used on dependencies that refer to
> modules that are part of the project (and therefore should be in the
> reactor), the assembly plugin ignores them and tries to resolve them from the
> local repository instead.
> The following project reproduces this issue (just "mvn clean package"):
> https://github.com/io7m/independent-versioning-20170207
> Interestingly, this didn't happen with the same assembly plugin on older
> Maven versions. Here's a successful build on Travis CI:
> https://travis-ci.org/io7m/independent-versioning-20170207
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
