>I am pretty much sure you are wrong: when you declare a dependency in Gradle
My claim is that the *meaning* of the declared version in Gradle doesn’t change between producer/consumer. If you have a small repro where the semantics change, please share — would love to see it. If you have Gradle documentation/specification that says producer/consumer impacts the semantics, please share — would love to see it. >In general, best practices for multi module builds are >well explained and documented: usually you do not have any version >except in top level POM (managed) Is it forbidden to declare versions in non-top-level module POMs? Maven does not forbid that, it does not fail the build, and it does not even issue a warning. Thus having versions mentioned explicitly is a valid use case. >instead gradually, first making them follow "best practice". What is your plan there? Look: I highlight an issue many Maven users face, and I suggest a concrete solution which does solve the issue, which goes in line with the behavior of the other dependency management engines, which does not break backward compatibility much and so on. Frankly, I am puzzled when you say <<gradually, first making them follow "best practice".>> Maven 3 was released 15 years ago. Maven 4 is about to come, and it does not solve NoClassDefFoundError either. What is the exact approach suggested by the Maven team? Tamás, you are on Maven PMC while I am not. You have much more power. Please take that into consideration. I've published a clear reproducer for the issue yet it looks like Maven team considers it a non-issue. See https://github.com/vlsi/mvn-mediation/tree/b82943ef7676dcf21927382eb1898cf984f10a8e/case3-standalone-with-direct-dep There's a new example (see case3-standalone-with-direct-dep). case 3 fails even with -Daether.conflictResolver.versionSelector.selectionStrategy=highest -Daether.dependencyCollector.bf.skipper=versioned. The application in "case 3" is more-or-less trivial, and I would expect many real-life tutorial and production appis would fall in the same trap, so what I mention does look like a true issue to me. What is the exact "best practice" you have in mind that everybody should follow? >I miss your point, what is "root module" according to you >(not reactor root, is it? as it cannot have code)? Frankly, it was you who defined <<We consider "root POM" the root of arborescence>> I think forcing users to think of "root POM" vs "non-root POM" when declaring versions is harmful. It creates issues while it provides no benefits except making the Maven engine a tiny bit faster. My idea was that Maven allows declaring versions in any POM, not just the root one, so it should be allowed to move both "dependency declaration" and "src/main/java/dependency_usage" across POMs. The app should still be runnable after moving the dependency and the code around. By the way, in case3, example-application consists of a single pom only yet it fails. So let's try to figure out Maven's vision on case3 before we discuss "root vs non-root" further. Vladimir
