For me the "goal to solve" is unclear: what is the problem that is to be solved?
User specifies in project POM direct dependency on 1.0.0 and then user expects that it somehow "magically" goes up to 2.0.0? Could you explain what you are really trying to achieve here? Should the build tool automatically update dependencies for you? Or what is the rationale behind explicitly specifying dependency on 1.0.0 and then expecting dependency on 2.0.0? Or to revert: if you want (and expect) 2.0.0, why on earth you depend on 1.0.0 in POM in the first place? T On Fri, Oct 10, 2025 at 11:28 PM Romain Manni-Bucau <[email protected]> wrote: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
