Nope, sorry. I am wrong here.... T
On Fri, Oct 10, 2025 at 10:49 PM Tamás Cservenák <[email protected]> wrote: > > 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]
