[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16053140#comment-16053140 ] Mark Raynsford commented on MASSEMBLY-848: -- Actually, this still seems to be a problem... I posted the above example as a simple reproduction case, but it's actually a much simplified version of a real project I was using as an experiment in independent module versioning: https://github.com/io7m/thoth The problem now is that because I have to use `moduleSets` to create a distribution zip containing the project jars and all dependencies, and because I have to use `false` in order to prevent Maven from trying to pick up the project's module jars from the local repos, the dependencies of each module are excluded... For example, the `com.io7m.thoth.command.system` module depends on `com.io7m.junreachable.core`, but `com.io7m.junreachable.core` is not included in the final distribution zip because transitive dependencies aren't followed. Is there some better way to do what I'm trying to do? > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052845#comment-16052845 ] Mark Raynsford commented on MASSEMBLY-848: -- > The original example does not work on Maven 3.0.5, 3.1.1, 3.2.5, 3.3.9 and > 3.5.0 https://s3.amazonaws.com/archive.travis-ci.org/jobs/199286373/log.txt ^ That's a log of it working on 3.2.5 (or perhaps failing to fail!). > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052825#comment-16052825 ] Karl Heinz Marbaise commented on MASSEMBLY-848: --- The original example does not work on Maven 3.0.5, 3.1.1, 3.2.5, 3.3.9 and 3.5.0. It is independent of the Maven version. The same output on all Maven versions. The problem is related to a wrong assumption, cause a dependencySet is something different than a moduleSet. In this case it is related to the moduleSet. And at the moment I don't see that there is an issue... > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052816#comment-16052816 ] Mark Raynsford commented on MASSEMBLY-848: -- Interesting, thank you. I'll try it shortly. I don't really understand why this now necessary on newer Maven versions. Did something fundamental change inside Maven that somehow changed the semantics of the Assembly plugin? > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16052312#comment-16052312 ] Karl Heinz Marbaise commented on MASSEMBLY-848: --- Using the following in your assembly descriptor should work: {code:xml} http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd;> distribution ${project.name}-${project.version} zip true false lib false false false {code} > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880791#comment-15880791 ] Mark Raynsford commented on MASSEMBLY-848: -- No, I'm sorry, I can't fix this. Something seems to be very fundamentally broken about how version ranges are handled and I have no idea how to fix it. Unless someone else steps up, this one is going to stay broken (which essentially makes the Assembly plugin useless for our purposes). > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15880621#comment-15880621 ] ASF GitHub Bot commented on MASSEMBLY-848: -- Github user io7m closed the pull request at: https://github.com/apache/maven-plugins/pull/104 > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15879190#comment-15879190 ] ASF GitHub Bot commented on MASSEMBLY-848: -- GitHub user io7m opened a pull request: https://github.com/apache/maven-plugins/pull/104 MASSEMBLY-848 Do not attempt to resolve reactor projects I'm submitting this pull request in the hope of getting some discussion on the issue. I feel like the submitted fix here is not the right way to solve this problem but do not understand enough of the way Maven resolves artifacts to be sure. This change does at least appear to resolve the provided integration test properly and does not break any existing tests. ``` This is an attempt at addressing MASSEMBLY-848: When resolving the dependencies of a project, we explicitly avoid attempting to resolve any dependency artifacts that are also reactor projects. ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/io7m/maven-plugins trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/104.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #104 commit c1c9576c7cedc3cfb06d79350251f2a4296b308c Author: Mark RaynsfordDate: 2017-02-22T20:36:09Z MASSEMBLY-848 Do not attempt to resolve reactor projects This is an attempt at addressing MASSEMBLY-848: When resolving the dependencies of a project, we explicitly avoid attempting to resolve any dependency artifacts that are also reactor projects. > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15873632#comment-15873632 ] Mark Raynsford commented on MASSEMBLY-848: -- Even worse: If a previous version of these artifacts have been installed and the current version range includes them, the old artifacts in the local repository will be used in preference to the reactor project artifacts. > 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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15857870#comment-15857870 ] Mark Raynsford commented on MASSEMBLY-848: -- This is also reproduceable with the current tip of the master branch of Maven (66a0fbe495f7df45562bee22188341899e1ca839). > 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)