Didier Loiseau created MNG-8295:
-----------------------------------
Summary: Dependency Manager Transitivity (now default) handles
dependency management inconsistently
Key: MNG-8295
URL: https://issues.apache.org/jira/browse/MNG-8295
Project: Maven
Issue Type: Bug
Components: API, Core
Affects Versions: 4.0.0-beta-4
Reporter: Didier Loiseau
Attachments: dependency-transitivity-inconsistency.zip
Since MNG-7982, {{maven.resolver.dependencyManagerTransitivity}} ({{{}true{}}}
by default) configures the {{ClassicDependencyManager}} with the corresponding
{{transitivity}} flag.
It appears, however, that this behavior is inconsistent, because it ignores the
dependency management of direct dependencies and only considers it for the
transitive dependencies.
I already described this in MNG-5761, but since the latter is a feature request
(that should have been implemented by MNG-7982), I thought it would make more
sense to track this inconsistency as a bug.
The attached [^dependency-transitivity-inconsistency.zip] (copied from
MNG-5761) can be used to show the issue.
I’m running with
{code:java}
$ 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}
First you can see that {{dependent-pom}} manages the version of
{{commons-collections}} to *3.2.2* ({{{}commons-beanutils:1.9.2{}}} depends on
3.2.1):
{code:java}
$ mvn dependency:tree -f dependent-pom.xml
…
[INFO] MNG-5761:dependent:pom:1.0-SNAPSHOT
[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}
Now install {{parent-pom}} and {{{}dependent-pom{}}}, and check the
dependencies of {{{}depending-pom{}}}:
{code:java}
$ mvn install -f parent-pom.xml
$ mvn install -f dependent-pom.xml
$ mvn dependency:tree -f depending-pom.xml
…
[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}
you can see that the {{<dependencyManagement>}} of {{dependent}} is ignored
(like with Maven 3), and we get {{commons-collections}} *3.2.1* instead.
However, if we install {{dependent-pom}} and check the dependencies of
{{{}dependent-pom2{}}}, we get:
{code:java}
$ mvn install -f depending-pom.xml
$ mvn dependency:tree -f depending-pom2.xml
…
[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}
So now we get {{commons-collections}} *3.2.2* again! {{<dependencyManagement>}}
is taken into account at depth 2+ (and 0) but not at depth 1.
This is due to [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}
I have also created [a PR with integration
tests|https://github.com/apache/maven-integration-testing/pull/379] for
MNG-7982, which shows the issue as well.
I simple fix would be to use the {{TransitiveDependencyManager}} when
{{{}{{{}maven.resolver.dependencyManagerTransitivity{}}}=true{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
