Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
4.0.0-beta-4
-
None
Description
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 originally a different issue (that should have been fixed by MNG-7982), I thought it would make more sense to track this inconsistency as a separate bug.
The attached dependency-transitivity-inconsistency.zip
(copied from MNG-5761) can be used to show the issue.
I’m running with
$ 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"
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):
$ 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
Now install parent-pom and dependent-pom, and check the dependencies of depending-pom:
$ 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
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:
$ 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
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 in ClassicDependencyManager:
@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);
}
I have also created a PR with integration tests for MNG-7982, which shows the issue as well.
I simple fix would be to use the TransitiveDependencyManager when maven.resolver.dependencyManagerTransitivity=true.
