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
