You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Mark Raynsford (JIRA)" <ji...@apache.org> on 2017/02/08 11:42:41 UTC

[jira] [Created] (MASSEMBLY-848) Version range dependencies not resolved from the reactor

Mark Raynsford created MASSEMBLY-848:
----------------------------------------

             Summary: 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


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)