[
https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543751#comment-14543751
]
Robert Scholte edited comment on MNG-5761 at 5/14/15 8:40 PM:
--------------------------------------------------------------
[~jvanzyl] this is reproducible.
For example:
{code:xml|title=parent_pom POM}
<dependencyManagement>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_T</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</dependencyManagement>
{code}
{code:xml|title=project_A POM}
...
<parent>
<groupId>...</groupId>
<artifactId>parent_pom</artifactId>
<version>...</version>
</parent>
....
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_B</artifactId>
<version>...</version>
</dependency>
</dependencies>
{code}
{code:xml|title=project_B POM}
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_T</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
{code}
{code:xml|title=project_C POM}
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_A</artifactId>
<version>...</version>
</dependency>
</dependencies>
{code}
Now:
1. running {{mvn dependency:tree}} from project_A will result in bringing
version 1.0 of project_T, which is correct.
2. running {{mvn dependency:tree}} from project_C will result in bringing
version 2.0 of project_T, which is incorrect (the same dependency management
rules should apply as at point 1, which is the expected.).
This same scenario, is also explained here
http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies.
was (Author: maria.petridean):
[~jvanzyl] this is reproducible.
For example:
parent_pom POM:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_T</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</dependencyManagement>
project_A POM:
...
<parent>
<groupId>...</groupId>
<artifactId>parent_pom</artifactId>
<version>...</version>
</parent>
....
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_B</artifactId>
<version>...</version>
</dependency>
</dependencies>
project_B POM:
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_T</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
project_C POM:
<dependencies>
<dependency>
<groupId>...</groupId>
<artifactId>project_A</artifactId>
<version>...</version>
</dependency>
</dependencies>
Now:
1. running mvn dependency:tree from project_A will result in bringing version
1.0 of project_T, which is correct.
2. running mvn dependency:tree from project_C will result in bringing version
2.0 of project_T, which is incorrect (the same dependency management rules
should apply as at point 1, which is the expected.).
This same scenario, is also explained here
http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies.
> <dependencyManagement> picks wrong version for transitive dependencies
> ----------------------------------------------------------------------
>
> Key: MNG-5761
> URL: https://issues.apache.org/jira/browse/MNG-5761
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 3.2.5
> Reporter: Jeff Schnitzer
> Assignee: Jason van Zyl
>
> A detailed description of the issue is here:
> http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies
> The short of it is that maven appears to be using the wrong
> <dependencyManagement> version in a transitive dependency. There are two
> relevant <dependencyManagement> sections in the build, one pulled in by guice
> and one pulled in by gwizard-parent. These are the dependency paths from the
> top:
> gwizard-example -> gwizard-config -> gwizard-parent
> gwizard-example -> gwizard-config -> guice -> guice-parent
> gwizard-parent's dependencyManagement specifies guava 18
> guice-parent's dependencyManagement specifies guava 16
> Guava 16 is winning. This seems highly undesirable, and in fact it breaks our
> build. I would expect that in a version # fight, "closest to the top" should
> win.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
