>* you respect it globally and there you do not solve the issue, you move it
I believe dependency management should be global at the classpath level. In the end we always produce one classpath, and we cannot load multiple versions of the same GAV there >so at the end it stays a very fragile solution which will look random for >end users Romain, I don’t see where “random” would come from. The resolution would be deterministic: same inputs -> same graph -> same classpath. If a library author publishes a platform POM (e.g., commons-compress 1.1.0) that manages its split modules, then bumping commons-compress-tar to 1.1.0 would consistently align commons-compress-xz to 1.1.0 as well. That mirrors what people already do with a shared commons-compress.version property; just without forcing every consumer to duplicate it at the root. Could you point to a concrete scenario where this yields a non-deterministic outcome for the end user? >gradle strategy works well except when it breaks Can you share specific examples where the behavior I’m proposing (honoring transitive dependencyManagement globally for the classpath) “breaks,” along with the expected vs. actual graphs? That would help us test and document guardrails. >take you exact case but with both dependencies being incompatible, what do >you do Do you mean: *1.1.0 is not backward-compatible with 1.0.0*? If so, Maven’s current behavior already can’t make that compatible. Today it will often pick 1.0.0 and the app fails at runtime where 1.1.0 is required. With my suggestion, if the producer’s POM manages 1.1.0, Maven can globally converge to 1.1.0, and the app will work provided 1.1.0 is backward-compatible for the parts actually used. If it’s not compatible, the app fails either way; the difference is we at least follow the producer’s declared intent instead of forcing each consumer to hand-craft excludes/re-adds. In other words: * Today: Maven often resolves to 1.0.0 -> runtime error unless the user manually curates versions. * With transitive DM honored: Maven can resolve to 1.1.0 (as the producer intended) which works in the common case of backward compatibility. Backward-compatible minor bumps are far more common than 50/50 in real libraries. This change reduces boilerplate and failure modes for the common path, while keeping behavior deterministic and explainable. Can you clarify the example? Frankly, I do not understand what you mean by "exact case but with both dependencies being incompatible". Did you mean a case when commons-compress:1.1 is not backwards-compatible with commons-compress:1.0? If the newer version is incompatible with an older version, then the existing Maven resolution won't help either. Maven will resolve to 1.0, and the final application would fail since some of the libraries requested commons-compress 1.1. If you still see “randomness,” please point to the *exact rule* that would be ambiguous from the end-user perspective. My proposal is simply: when computing the single classpath, *include versions from transitive dependencyManagement*published by artifacts already in the graph. Vladimir
