Howdy, IIUC, is it "transitive dependency management"?
As if it is, it is how Maven 4 will work, see here: https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Constants.java#L411-L423 Grab a snapshot from here and give it a try https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-SNAPSHOT/ HTH T On Fri, Oct 10, 2025 at 10:16 PM Vladimir Sitnikov <[email protected]> wrote: > > Hello Maven developers, > > I'd like to propose an enhancement to how Maven handles > dependencyManagement sections in the dependency resolution chain. > Currently, Maven only honors the dependencyManagement section from the > direct consumer POM, but I believe > there would be significant benefits to honoring dependencyManagement > declarations in intermediate POMs as well. > # Current Situation > When a project depends on an artifact that itself has a > dependencyManagement section, Maven ignores that intermediate > dependencyManagement during transitive dependency resolution. Only the root > project's dependencyManagement is considered. > > # Proposal > Honor dependencyManagement sections throughout the dependency chain, > allowing intermediate artifacts to manage versions of their related > dependencies more effectively. > > # Example & Demonstration > I've created a demonstration project that illustrates this scenario and the > benefits of the proposed change: [1] > > The example shows a common pattern where a library wants to split from a > monolithic JAR into multiple specialized modules while maintaining > compatibility. > > # Benefits > This change would provide two key improvements: > 1. Version Alignment Across Related Modules > Libraries that split into multiple artifacts (like commons-compress-tar, > commons-compress, and commons-compress-core in my example) > could ensure consistent versions across all their modules. > The parent artifact could use dependencyManagement to guarantee that all > related modules use compatible versions, > preventing version mismatches that can cause runtime issues. > > 2. Simplified Migration Path for Library Modularization > When libraries evolve from a single-jar to a multi-jar structure, this > feature would allow them to: > > * Maintain backward compatibility without package renaming > * Provide a smoother migration path for consumers > * Reduce the burden on downstream projects during the transition > > #Real-World Impact > Many projects face challenges when: > * Large libraries want to modularize (users shouldn't need all modules) > * Security or compatibility requires consistent versions across related > artifacts > * Projects need to evolve their structure without breaking existing > consumers > > Well-known projects already use this pattern to align versions (see > dependencyManagement): > * JUnit [2] > * Apache JMeter [3] > > I am sure Maven users would get better builds if Maven supported > dependencyManagement for intermediate POMs. > > #Discussion Points > I understand this would be a significant change to Maven's dependency > resolution mechanism, and I'm interested in discussing: > > * Potential compatibility concerns > * Whether this could be an opt-in feature initially > * Alternative approaches to achieve similar goals > > Would the team be open to considering this enhancement? > I'm happy to provide more detailed examples, help with implementation, or > clarify any aspects of this proposal. > > [1]: https://github.com/vlsi/jarsplit > [2]: > https://repo1.maven.org/maven2/org/junit/jupiter/junit-jupiter-api/6.0.0/junit-jupiter-api-6.0.0.pom > [3]: > https://repo1.maven.org/maven2/org/apache/jmeter/ApacheJMeter_functions/5.6.3/ApacheJMeter_functions-5.6.3.pom > > Regards, > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
