[
https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887084#comment-17887084
]
Didier Loiseau edited comment on MNG-5761 at 10/5/24 10:30 AM:
---------------------------------------------------------------
[~cstamas], I just checked with
{code:bash}
$ mvn -v
Apache Maven 4.0.0-beta-4 (697c543b4e3bbec1b99e9d4d1ee8e0302e748f09)
Maven home: /home/didier/.sdkman/candidates/maven/4.0.0-beta-4
Java version: 21.0.2, vendor: Oracle Corporation, runtime:
/home/didier/.sdkman/candidates/java/21.0.2-open
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"
{code}
and it does not fix the issue… for first level dependencies.
So basically, it does not fix it for the attached [^MNG-5761.zip] provided by
[~slanglois], you still get the same output as in his comment:
{code:bash}
$ mvn dependency:tree -f depending-pom.xml
…
[INFO] --- dependency:3.8.0:tree (default-cli) @ depending ---
[INFO] MNG-5761:depending:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.1:compile
{code}
However, if you add another level, as with [^depending-pom2.xml], you get the
expected output ({{{}commons-collections:jar:3.2.2{}}}):
{code:bash}
$ mvn install -f depending-pom.xml
$ mvn dependency:tree -f depending-pom2.xml
…
[INFO] --- dependency:3.8.0:tree (default-cli) @ depending2 ---
[INFO] MNG-5761:depending2:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:depending:pom:1.0-SNAPSHOT:compile
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \-
commons-collections:commons-collections:jar:3.2.2:compile{code}
The issue seems to come from [these 3
lines|https://github.com/apache/maven-resolver/blob/32844e4eb8d444838953f1d49be2ecb71db15b78/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L91-L93]
in {{{}ClassicDependencyManager{}}}:
{code:java}
@Override
public DependencyManager deriveChildManager(DependencyCollectionContext
context) {
// MNG-4720: Maven2 backward compatibility
// Removing this IF makes one IT fail here (read comment above):
//
https://github.com/apache/maven-integration-testing/blob/b4e8fd52b99a058336f9c7c5ec44fdbc1427759c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java#L67
if (depth == 1) {
return newInstance(managedVersions, managedScopes,
managedOptionals, managedLocalPaths, managedExclusions);
}
return super.deriveChildManager(context);
}
{code}
Basically, it ignores the context for the first level of dependencies. This
seems to be reminiscent from [the implementation Resolver
1.9|https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.22/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L85-L92],
where it was the case for all layers above 1.
I guess this logic shouldn’t apply if {{{}deriveUntil > 2{}}}? Otherwise it’s
quite inconsistent.
This would make the behaviour almost identical to the
{{DefaultDependencyManager}} though, so I’m wondering why the latter isn’t used
instead (and its name makes that even more confusing). I suppose it affects the
management of exclusions?
Edit: actually that behavior would be the one of
{{TransitiveDependencyManager}} (still not sure about the {{deriveUntil}}
effects)
was (Author: didier loiseau):
[~cstamas], I just checked with
{code:bash}
$ mvn -v
Apache Maven 4.0.0-beta-4 (697c543b4e3bbec1b99e9d4d1ee8e0302e748f09)
Maven home: /home/didier/.sdkman/candidates/maven/4.0.0-beta-4
Java version: 21.0.2, vendor: Oracle Corporation, runtime:
/home/didier/.sdkman/candidates/java/21.0.2-open
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "6.8.0-45-generic", arch: "amd64", family: "unix"
{code}
and it does not fix the issue… for first level dependencies.
So basically, it does not fix it for the attached [^MNG-5761.zip] provided by
[~slanglois], you still get the same output as in his comment:
{code:bash}
$ mvn dependency:tree -f depending-pom.xml
…
[INFO] --- dependency:3.8.0:tree (default-cli) @ depending ---
[INFO] MNG-5761:depending:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \- commons-collections:commons-collections:jar:3.2.1:compile
{code}
However, if you add another level, as with [^depending-pom2.xml], you get the
expected output ({{{}commons-collections:jar:3.2.2{}}}):
{code:bash}
$ mvn install -f depending-pom.xml
$ mvn dependency:tree -f depending-pom2.xml
…
[INFO] --- dependency:3.8.0:tree (default-cli) @ depending2 ---
[INFO] MNG-5761:depending2:pom:1.0-SNAPSHOT
[INFO] \- MNG-5761:depending:pom:1.0-SNAPSHOT:compile
[INFO] \- MNG-5761:dependent:pom:1.0-SNAPSHOT:compile
[INFO] \- commons-beanutils:commons-beanutils:jar:1.9.2:compile
[INFO] +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] \-
commons-collections:commons-collections:jar:3.2.2:compile{code}
The issue seems to come from [these 3
lines|https://github.com/apache/maven-resolver/blob/32844e4eb8d444838953f1d49be2ecb71db15b78/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L91-L93]
in {{{}ClassicDependencyManager{}}}:
{code:java}
@Override
public DependencyManager deriveChildManager(DependencyCollectionContext
context) {
// MNG-4720: Maven2 backward compatibility
// Removing this IF makes one IT fail here (read comment above):
//
https://github.com/apache/maven-integration-testing/blob/b4e8fd52b99a058336f9c7c5ec44fdbc1427759c/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java#L67
if (depth == 1) {
return newInstance(managedVersions, managedScopes,
managedOptionals, managedLocalPaths, managedExclusions);
}
return super.deriveChildManager(context);
}
{code}
Basically, it ignores the context for the first level of dependencies. This
seems to be reminiscent from [the implementation Resolver
1.9|https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.22/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/ClassicDependencyManager.java#L85-L92],
where it was the case for all layers above 1.
I guess this logic shouldn’t apply if {{{}deriveUntil > 2{}}}? Otherwise it’s
quite inconsistent.
This would make the behaviour almost identical to the
{{DefaultDependencyManager}} though, so I’m wondering why the latter isn’t used
instead (and its name makes that even more confusing). I suppose it affects the
management of exclusions?
> Dependency management is not transitive.
> ----------------------------------------
>
> 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
> Priority: Critical
> Fix For: 4.0.x-candidate
>
> Attachments: MNG-5761.zip, depending-pom2.xml
>
>
> 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
(v8.20.10#820010)
