[
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052859#comment-16052859
]
Karl Heinz Marbaise commented on MASSEMBLY-848:
-----------------------------------------------
I have taken the above link to github and cloned that and tested that with each
Maven version which failed (I used {{mvn clean package}})...The point here is
that you have used {{mvn install}} instead of {{mvn package}} which is
something different.
If you do a {{mvn install}} each module of that multi module build will be
iterated over. The first one will do the life cycle including installing the
artifact into local cache {{$HOME/.m2/repository}} the next module etc. and so
until the last module {{mod-c}} which has the maven-assembly-plugin
configuration which now resolves the dependencies from the local cache which
works. This will work with all Maven versions cause it's independent of the
Maven version.
If you like to do {{mvn clean package}} that will fail for all Maven versions
cause they are not solved from the reactor only if artifacts have the same
version this will work...
I never use {{mvn clean install}} on multi module builds. I always use {{mvn
clean package}}...and that's the issue here. The resolution will not work for
those dependencies from the reactor cause they have different version numbers
and they will be tried to resolve from remote repository in which they did not
exist...If you use the example I have shown this will work also with {{mvn
clean package}}...
> 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.4.14#64029)
