My 2cts are that transitive deps never set what you need in depMgt until scoped to their own groupid/ecosystem or when you get luck they release at the some time than cause do sounds like the promise of issues and need to manual overrides to me.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 10 oct. 2025, 23:15, Tamás Cservenák <[email protected]> a écrit : > So, with direct deps this does not make sense to me, but it works with > transitive deps: > https://gist.github.com/cstamas/bd9f18a1ce5781d6a9b6f0472812c12a > > Maven will never-ever override what you told it to do, if 1.0.0, then > it is 1.0.0. You know the best. > > HTH > T > > On Fri, Oct 10, 2025 at 11:03 PM Tamás Cservenák <[email protected]> > wrote: > > > > Is late for me, but for start, you have authored this POM: > > https://github.com/vlsi/jarsplit/blob/main/lib-user-maven4/pom.xml > > And then you expect that Maven plainly ignores what you instructed it > > to do, and "come up" with some better plan? > > (to pick another dependency over the one you specd?) > > > > T > > > > On Fri, Oct 10, 2025 at 10:55 PM Tamás Cservenák <[email protected]> > wrote: > > > > > > 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] > >
