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]
