Howdy, The spec "if no other version appears earlier in the dependency tree" is very very good, as you took it from the Maven site, which contains documentation for released Maven, which today is 3.9.11. What we talk about here is not present in any released Maven 3, hence is not documented nor spec'd on site.
And yes, IF we get highest support (again, it is not supported today, as we have just a bunch of hacks/knobs and levers to experiment with), hopefully will get documented as well. So please, bear with me: we are in "uncharted (undocumented) territory" with all this. In Maven, we don't have "version enforcement", we have "version management". Also, you are conflating several things here: - if lib can work ONLY with guava 30.1-jre and NOT OTHER guava version, they yes, it could use "hard" version of "[30.1-jre]" (and be very unfriendly lib to work with) - but, IF this above is true, then your whole example loses sense; as you want lib-a and lib-b to work together on a flat classpath (my point: a lot of "what if...." just leads us nowhere, makes us spend cycles endlessly) You _usually_ what to enforce JAR versions in some sort of "end product", like for example a WAR or a deliverable "distro" like a zip/tarball is. Again, such a thing is usually what YOU author (or assemble), as today we all "assemble" apps/distros from other OSS components (mostly). And for your example of multi-module build (I told you to neglect those in some prev mail; for simplicity sake!): there is a fundamental difference you miss, in first case you build it, in second you consume it. That is very not the same thing. It completely modifies the "context" in which the POM is being used. Just an example, if you do `mvn install -f lib-a` and then `mvn install -f example-project`, the lib-a is being used from local repository, just like any other dependency not in your reactor, for example guava and guice pulled and cached from central. It is the "context" that is being modified, not the "versions" per se, for example, where are the test scoped deps of lib-a when consumed as dependency? Isn't that misleading too then? And yes, POM (in fact, POM is only the "carrier" when consumed as dep) does get altered, well _interpreted differently_, depending on context: - when you build lib-a - when you consume lib-a - when you consume lib-a fx in test scope (Q: what happens with lib-a deps now?) - when you consume lib-a along with lib-b? - etc I used arborescence only to show you there is a node called "root", that's all. T On Thu, Oct 23, 2025 at 3:20 PM Vladimir Sitnikov <[email protected]> wrote: > > >Hence, the written spec "Use 1.0 if no other version appears earlier > in the dependency tree" is fine. > > It is not fine for "selectionStrategy=highest skipper=versioned" > > The specification should provide users with clear ways to interpret the > meanings. > Please suggest what would you spell out exactly. > > "if no other version appears earlier in the dependency tree" is wrong since > the version > could be superseded by a version declared somewhere in the sibling. > > In other words, the reproducer project has NO "other version > appears earlier in the dependency tree" yet it selects a newer version > instead. > > That is why I say the definition should be reworded. > > >The beauty is that with this in mind > > Consider the test project: > https://github.com/vlsi/mvn-mediation/blob/dd5f3a484634c04fb36da22e931cd51be2a68e6c/lib-a/pom.xml#L21 > How could lib-a enforce guava to be 30.1-jre exactly? > Apparently, lib-a is not a root pom, so do you mean "version enforcement" > could be done in a root pom only? > > >The beauty is that with this in mind > > One more note: the same pom could be both root and non-root depending on > the way you launch Maven. > For instance, in the mvn-mediation project I can execute lib-a both as a > root project, and as a part of the composite. > I don't think it looks beautiful if the meaning of lib-a/pom.xml versions > changes depending on the way I execute it. > > >I don't know how Human Interfaces and "modes" came into play > > Hey Tamás, I've quoted a book. > Here's a simplified description: > https://en.wikipedia.org/wiki/The_Humane_Interface > >Wikipedia: a mode is a state in which the computer produces a different > output for the same input than it would have if it were another state > > Then I quoted the reason I connect "root vs non-root" vs mode: > > >Vladimir: If we consider "root POM" to be special, then the same input > (==same POM) > > would have different meaning depending on the state (if the POM is root > or not). > > Frankly, I do not see how Arborescence_(graph_theory) explains the benefits > of > having different interpretations for the same <version>1.0</version> > depending if the > version is placed in a root pom or not. > > If a user wants to enforce a specific version, it would be way easier to > get it done with [1.0] > or an alternative _explicit_ way. > Then everybody would understand there was explicit intention to enforce the > version. > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
