Let me please reiterate the issue with a clearer, minor-version example. I updated the reproducer ([1]):
1) Use 1.0 -> 1.1 (no "v2 might be breaking" ambiguity). 2) commons-compress-tar:1.1.0 adds a *new method* to demonstrate Maven's *runtime* failure 3) I've added dependencies (svg, http) to mimic real-world usage *Claim (what I’m showing)With Maven 4 today, a library author cannot safely split a monolithic artifact into several modules andrelease it as a backward-compatible minor version (e.g., 1.1.0) without coordinated changes in downstream applications.* Minimal test case: * app-maven4 application uses only svg and http libraries; it's build with Maven 4 * commons-compress splits into multiple modules and releases 1.1.0 * http:1.1.0 adopts fine-grained commons-compress-tar:1.1.0 * The app app-maven4 bumps http from 1.0.0 to 1.1.0 * *Result*: NoSuchMethodError ... TarCompressor.methodAddedIn11 in the runtime Note that the user application fails *even in the case commons-compress maintains full backward compatibility*. This happens *even when* commons-compress:1.1.0 *is backward-compatible* for consumers; the failure is caused by resolution not aligning related commons-compress-* modules Known workarounds (and why they're not sufficient): a) Exclude commons-compress transitive deps from svg/http and re-add the desired ones explicitly. b) Add explicit dependencyManagement for commons-compress to the app's root POM. Both require *application-side* curation and ongoing maintenance. If svg/http later stop using commons-compress, the app must be updated again. In effect, the *producer cannot split* without the *consumer editing their POM*, which is exactly what we’d like to avoid for a backward-compatible minor. However, both workarounds require changes to the application pom, and both workarounds require app developer to figure out the compress version, and maintain the workaround. For instance, if both svg and http stop using commons-compress, the app developer would need to remove commons-compress from their pom as well. *The Maven issue restricts commons-compress vendor from splitting the artifact without coordinated changes to all the applications*. Note: Gradle builds of the same scenario continue to run after the http version bump, i.e., they are not affected by this artifact-split scenario. *What I’m asking* Can we consider changing Maven 4 resolution so that transitive <dependencyManagement> is honored at classpath scope, enabling version alignment across a module family (e.g., commons-compress-*) when a producer ships a split minor? This would let library authors split/merge modules without forcing each application to hand-craft excludes or duplicate management blocks. If you see a better mechanism than transitive <dependencyManagement> to enable seamless artifact splits, I’m all ears—please suggest it. [1] https://github.com/vlsi/jarsplit Vladimir
