[ 
https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052862#comment-16052862
 ] 

Mark Raynsford commented on MASSEMBLY-848:
------------------------------------------

Understood. Thank you!

> 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)

Reply via email to