I've raised the following: https://github.com/apache/maven/issues/11391
Comments welcomed. Le ven. 31 oct. 2025 à 14:44, Vladimir Sitnikov <[email protected]> a écrit : > >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 > -- ------------------------ Guillaume Nodet
