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

[Mark Raynsford (JIRA)]

[ 
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

[Mark Raynsford (JIRA)]

[ 
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

[Karl Heinz Marbaise (JIRA)]

[ 
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

[Mark Raynsford (JIRA)]

[ 
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

[Karl Heinz Marbaise (JIRA)]

[ 
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

[Mark Raynsford (JIRA)]

[ 
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

[Karl Heinz Marbaise (JIRA)]

[ 
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

[Mark Raynsford (JIRA)]

[ 
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

[ASF GitHub Bot (JIRA)]

[ 
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

[ASF GitHub Bot (JIRA)]

[ 
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 Raynsford 
Date:   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

[Mark Raynsford (JIRA)]

[ 
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

[Mark Raynsford (JIRA)]

[ 
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

[Mark Raynsford (JIRA)]

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