Hi Vladimir, On 9.10.2025 09:29, Vladimir Sitnikov wrote: > Gradle is not affected by JLBP-6's "Case 2: Rename Maven ID", and it honors > transitive BOMs, so it > bumps commons-compress from 1.0.0 to 2.0.0 as soon as it observes > commons-compress-core:2.0.0 on the classpath. > > [...] > > I've found [2], which is "closed, fixed in 4.0.0"; however, my tests show > Maven 4.0.0-rc-4 does not resolve the issue. > Either I'm testing it incorrectly, or the issue is not fixed in Maven 4.0. > I assume it is reasonable to expect Maven to select commons-compress:2.0.0 > in this case. > Is there a reason BOMs are only applied when explicitly imported by the > direct consumer? > > [...] > > [2] https://issues.apache.org/jira/browse/MNG-5761
I believe MNG-5761 addresses a different problem than JLBP-6 Case 2 (renaming Maven GA while keeping package names). MNG-5761 concerns a level-2 dependency’s <dependencyManagement> not being applied to resolve a level-3 dependency in the same branch. Our situation is different: if commons-compress were renamed to commons-compress-core, an application might simultaneously have: - commons-compress 1.x as a transitive dependency in one branch, and - commons-compress-core 2.x as a transitive dependency in another. What we’d want is for commons-compress-core’s <dependencyManagement> to be imported automatically so it governs which version of commons-compress is chosen *elsewhere* in the graph, without requiring an explicit BOM import by the top-level consumer. Gradle does support something along these lines (see Jendrik’s post on automatic alignment with Gradle Module Metadata) [1]. However, we can’t rely on that behavior universally: 1. The Java ecosystem uses many build tools (Maven, Gradle, Bazel, sbt, Spring Boot’s dependency-management plugin, etc.). Even if Maven and Gradle converge, others may not. 2. Building a global <dependencyManagement> from downstream dependencies is inherently iterative: managed versions influence the graph, which in turn could change what gets managed. Different tools may make different approximations, and convergence isn’t guaranteed. To stay compatible across build managers, we’re left with the options in JLBP-6: 1. Keep the commons-compress artifact name for the core library, move specific archivers/compressors to separate artifacts, and rename their packages. (With log4j-core 3 we chose this approach, since log4j-core shouldn’t be a transitive dependency anyway.) 2. Use entirely new packages and Maven coordinates so users can keep a working 1.x alongside 2.x on the classpath. Piotr [1] https://blog.gradle.org/alignment-with-gradle-module-metadata --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
