Hi Vladimir, Le lun. 13 oct. 2025 à 18:30, Vladimir Sitnikov <[email protected]> a écrit :
> >* 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. > No, depends if another lib does the same and it is common to thave that case for commons* as mentionned. > That mirrors what people already do with a shared commons-compress.version > property; > just without forcing every consumer to duplicate it at the root. > Yes but still need the hack I mentionned, ie control the dependencies you bring back, no transitive magic. For the record we had that bug that transitive props were overriding root ones at some point (were "respected" for you) and it totally broke projects, understanding so I do not see how it can help. Also note that what you propose, ie to make it automagically work, is literally to enforce end user to review any transitive pom to ensure what happens in his pom is what he expected or understand it, sounds a time killer, even with AI. > > Could you point to a concrete scenario where this yields a > non-deterministic outcome for the end user? > I didn't ay non deterministic but it looks like so since it is deterministic just cause the pom has an order, change this order and the resolution will defer a lot due to something you do not define yourself. While acceptable to resolve dependency version, it is not about the full (g)av. > > >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. > This is wrong, depends on multiple factors, it will be as often 1.0.0 as 1.1.0, depends your pom but it is simple to solve since dependency tree is explicit and not indirected over multiple projects. But ack it must be resolved explicitly in the consumer project pom. > > 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. > Without your suggestion too - as of today. > 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. > Once again means you need to resolve conflicts, you just moved the problem to depMgt and not dep only which is harder to debug and understand for no real gain in pactise. > > 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. > You implicitly assume semver is everywhere? If so I'm not sure we must enter that but then it is about conflict resolution and not dependency mgt resolution at all for me. > > 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. > Are you able to explain how it is different fro musing dependency? (spoiler: it is not) Can you confirm you assume semver and this is the key which makes it working for you and that ultimately depMgt is totally unrelated to the solution in terms of conflict resolution? > > Vladimir >
