There are only two options for me: * either you respect the transitive dep mgt for the sub graph and it can work if no overlapping with any other dependencies (so almost never for commons*) * you respect it globally and there you do not solve the issue, you move it
so at the end it stays a very fragile solution which will look random for end users (you keep saying "honor metadata" but this is true in a context which is not your app only so irrelevant for your use case) whatever option you pick and will not help to have robust projects IMHO gradle strategy works well except when it breaks, this kind of option has pro and cons and we are literally at 50-50 there, the choice is "try to make some magic and be awesome when it works" vs "always be deterministic from end user perspective and simple to understand". I'm clearly in last camp and I think a toggle would be negative overall. > So I don't understand what you mean by "it doesn't solve your issue exactly". take you exact case but with both dependencies being incompatible, what do you do 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 dim. 12 oct. 2025 à 18:22, Vladimir Sitnikov <[email protected]> a écrit : > Thanks. I think we’re still talking past each other a bit. > I’m not asking Maven to guess replacements between unrelated artifacts. > I’m asking Maven to *honor producer-provided BOM/dependencyManagement that* > *already exists in transitive POMs*so consumers don’t have to duplicate it. > > Versioning note to avoid the “v2 must change packages/GAV” objection > > To be crystal clear: the “split a single JAR into several modules” change > can be shipped as commons-compress:1.1.0 (not 2.0). > Same Java packages, backward-compatible APIs; the only change is > modularization (e.g., commons-compress-core, commons-compress-tar, …) > and a top-level commons-compress POM that manages those modules. > This avoids any “Commons convention for v2” discussion entirely. Users who > still depend on commons-compress:1.x get a normal minor upgrade path; > newer users can depend on specific modules. > > The request > > Today, if lib-uses-v1 and lib-uses-v2 are brought together, newcomers must > learn to exclude and > re-add versions at the root or adopt wrappers/BOMs. > My request is to let Maven let Maven auto-honor such transitive management > from artifacts that are actually in the selected graph. > This is not “silent magic”; it’s following the producer’s metadata > > Why core/resolver (not just a plugin) > > Plugins run after resolution. The split/merge intent is a resolution > concern (similar in spirit to relocation, which handles 1 -> 1). > This proposal addresses the 1 -> N (or N -> 1) case using standard BOM > semantics, only when explicitly allowed. > > Addressing your points > > “Artifacts are different; tool can’t choose.” > Agreed. That’s why the *producer* *opts in *and narrows the scope. > The tool is not choosing at random; it is honoring producer metadata > already shipped for consumers. > > “Use a BOM/wrapper; that’s the integrator’s job.” > True today, but it creates repeated boilerplate and foot-guns for mixed > ecosystems. > The proposal *reduces that friction* without changing expert workflows. > > “It moves the issue one step further.” > Could you please clarify with a concrete example? > Frankly, a very similar behavior works well in Gradle, and it does help a > lot to align the versions. > My proposal *does fix the issue* when Gradle builds the project. *I don't > have to guide Gradle manually* to converge on the right commons-compress. > So I don't understand what you mean by "it doesn't solve your issue > exactly". > > Vladimir >
