Let me add my two cents here. > In other words, I would like Maven to select a highest version among the > versions mentioned in <dependencies> and <dependencyManagement> blocks in > my transitive dependency poms.
This assumes that the new version is backward compatible with older one, which in common case is not correct. Especially the mentioned Guava :) 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, but not to rely on any of those two transitive dependency branches "opinions". Using newer version is a quite weak criteria even if it looks so obvious and is indeed deterministic. To fail-fast on such cases I'd use maven-enforcer-plugin with <DependencyConvergence><uniqueVersions>false</uniqueVersions></DependencyConvergence> rule enabled. I really like current way of declaring of maven dependencyManagement where you can declare everything in a parent like import boms in the right order. Worth to mention that biggest maven project I work with has >1000 modules and >700 library dependencies and it works quite fine with currect maven 3.9. > The example shows a common pattern where a library wants to split from a > monolithic JAR into multiple specialized modules while maintaining > compatibility. This decision should be a problem of library author, but not the army of Maven users who will have breaking behavior on the Maven update. Note that changing default algorithm will lead to inconsistent builds depending on actual maven version (unless there is an enforcer plugin checking it). If there is a breaking change like this, the "bom" artifact should be released as well, the release migration readme should be provided and a major version must be increased. Some thoughts/advices 1. Don't split libraries. Not joking. Many libraries like apache httpclient suffer from it as they are quite senstive to matching httpcore, httpclient and httpasyncclient. Moreover these libraries have separate release cycles = own versions so it's not that easy to find a working combination. If it was a single jar, there were no problems like this. 2. Use shade plugin instead of transitive dependencies that may break 3. Create built-in self-validation of the classpath in your library. E.g. slf4j in a fail-safe manner prints warning if founds more than one slf4j implementation. JUnit prints warnings that library versions are inconsistent when catches failures like AbstractMethodNotImplemented, NoClassDefFoundError, etc. 4. If you really want to make a breaking change like new artifactId, change the package name. Like commons-lang3 did, like Jackson 3, like Swagger 3 did. 5. Use maven-enforcer-plugin in your projects (not libraries) 6. Use plugins (don't remember exact name) that verify there are no classpath duplications on your project (not libraries) 7. Have you considered maven "<distributionManagement><relocation>" pom artifacts like org.hibernate:hibernate-jpamodelgen:6.4.1.Final <https://repo1.maven.org/maven2/org/hibernate/hibernate-jpamodelgen/6.4.1.Final/hibernate-jpamodelgen-6.4.1.Final.pom> pom which are actually a reference to another artifact with the new name (org.hibernate.orm:hibernate-jpamodelgen)? Does it solve the problem? Also some comments regarding references. * Not sure that Gradle is a good example. For me it is always a huge headache to manage dependencies for a big project. On the opposite, in Maven I'm confident how to do it because inheritance is simpler than composite, it's straightforward and deterministic in current implementation. * JUnit/Hamcrest are also not very good examples as these are test libraries and risks there are quite low. Overall: -1 for the proposal On Thu, Nov 6, 2025 at 7:48 AM Vladimir Sitnikov < [email protected]> wrote: > >since you have conflict in transitive > >pom - depMgt or not, the only one able to solve the conflict in a relevant > >manner is the integrator *by design*. > > Romain, this literally means "all conflicts must be solved by the > integrator, and the tool > must not have automatic conflict resolution". > > It implies Maven should stop doing its "nearest wins" conflict resolution > and defer to the integrator > to resolve the conflicts. > > If you think Maven should drop automatic conflict resolution, go ahead, and > suggest your proposals > on a different thread please. > > In this thread I suggest improvements to the **existing** **automatic** > conflict resolution to make it > even better for the end-users. > > Vladimir >
