Please Vladimir take time to consume the info you got over the week end. Side note enforced solves it as it got written multiple Times cause enforced a single version résolution so no résolution needed at all nor platform, it is more robuste than anything else we spike about at the cost of integrators doing their job.
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 jeu. 6 nov. 2025, 13:30, Vladimir Sitnikov <[email protected]> a écrit : > >This assumes that the new version is backward compatible with older one, > >which in common case is not correct. Especially the mentioned Guava :) > > Sergey, there's no such assumption. > Please clarify the exact case when you think my proposal breaks users' > projects. > > >users who will have breaking behavior on the Maven update > > Please clarify the exact breakages you envision. > > >If I have lib-a and lib-b depending on the same library of different > >versions, I want to declare the exact version in my project > > Sure you can declare every possible transitive dependency in your root > pom.xml. > However, it would be wasteful practice for many simple projects. > > So far it sounds like you say you are used to Maven quirks, and you provide > no > cases when my suggestion would break your or somebody else's workflow. > > >1. Don't split libraries > >Many libraries like apache httpclient > >suffer from it as they are quite senstive to matching httpcore, httpclient > >and httpasyncclient > > Sergey, it is exactly the issue I mention: automatic alignment is needed. > With my proposal, apache httpclient authors would have a way to > configure poms in such a way so httpcore, httpclient align to the same (or > whatever workable) versions. > > >2. Use shade plugin instead of transitive dependencies that may break > > Shade plugin does not help for httpclient/log4j/guava/.. cases. > Sure it is helpful sometimes, however, it is unreasonable to go with > shading by default. > > >3. Create built-in self-validation of the classpath in your library > > It does not solve the issue I highlight. > Please execute the reproducer and suggest how "self-validation" would fix > the runtime failure. > > >4. If you really want to make a breaking change like new artifactId, > > It does not solve the issue I highlight. > Please execute the reproducer. It makes zero breaking changes. > > >5. Use maven-enforcer-plugin in your projects (not libraries) > > It does not solve the issue I highlight. > I do not see how maven-enforcer fixes the runtime faliure. > > >7. Have you considered maven "<distributionManagement><relocation>" pom > > Relocation is a different thing, and it does not solve the issue. > > Vladimir >
