Howdy, Enforcing is more like "intervention" as without it, your end result does not match what you want. In an ideal world, you would not need to intervene. But life is life.
(no, i did not say anywhere that user should list every dep explicitly) > At the same time, if I develop a library then it is not like I want to > "enforce jar versions" > It is more like I want to specify versions so the tests execute. And that is what happens when you specify dependency on lib-a "1.0", you get "1.0" on test classpath (among other test deps) and your tests will execute according to your specs. OTOH, as we have shown in this very thread, when your lib-a is consumed, you MAY NOT end up with "1.0" but with some other version... This copy-pasta of <dependencies> is again a "what if..." sort of thing IMHO. 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). So, copy-pasting <dependencies> section will alter the structure of the tree (pulling up or down things), but would not alter versions (as they should be managed in top level POM). Still, I understand there are wild projects out there, but I'd not try to "magically" fix all of them, instead gradually, first making them follow "best practice". Similarly, what do you mean by "move code between root and non root modules"? I miss your point, what is "root module" according to you (not reactor root, is it? as it cannot have code)? I am pretty much sure you are wrong: when you declare a dependency in Gradle, in that module, at build time, you will get that version (assuming no other magic overrides it), but when build output is consumed? Do you still get the same version? Or do you mean something like "within a multi module build"? As in that case, see above, same thing in Maven. T On Thu, Oct 23, 2025 at 4:55 PM Vladimir Sitnikov <[email protected]> wrote: > > >IF this above is true, then your whole example loses sense > > Do you expect me to file a sample application every time I suggest > something? > Frankly, I thought the need for "enforce version downgrade when being a > library" is clear. > > However, it sounds strange to hear "whole example losing sense". > Sure the current app example would fail every time if one of the libs > requires downgrade. > There are valid cases when downgrade is needed, so there should be ways to > make it happen. > > >as you took it from the Maven site, which contains > >documentation for released Maven, which today is 3.9.11 > > Well, of course I do not discuss Maven 3.9.11, and I keep repeating > "selectionStrategy=highest skipper=versioned" virtually in every mail. > Of course, I am interested in discussing the way forward with some future > Maven version. > > >IF we get highest support > >hopefully will get documented as well > > That's what I mean by "earlier in the dependency tree" does not work for > the new behaviour. > > Exact quote: > >Vladimir: Apparently, selectionStrategy=highest skipper=versioned changes > the behavior > >for "1.0 soft requirement" as "if no other version appears earlier in the > dependency tree" becomes invalid > > >So please, bear with me: we are in "uncharted (undocumented) > >territory" with all this. > > That is why I ask you to clarify why do you think it still makes sense to > keep "if no other version appears earlier in the dependency tree" > behavior for "selectionStrategy=highest skipper=versioned". > > I think "if no other version appears earlier in the dependency tree" makes > sense only with "nearest wins", > and if there's no "nearest wins", then making special treatment for the > root POM is a bad thing to do. > > >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. > > +1. > Typically, application vendor indeed wants to specify versions. > For instance, in Apache JMeter, the application release includes 141 jars, > and I do not think we enforce each and every version there. > > Do you mean Maven **requires** users to list each and every transitive > dependency explicitly in the pom file? > > At the same time, if I develop a library then it is not like I want to > "enforce jar versions" > It is more like I want to specify versions so the tests execute. > So even if I list dependency **directly** in the root pom file of my > library, it does not necessarily mean > I want to enforce the exact versions. > > >it could use "hard" version of "[30.1-jre]" (and be very unfriendly lib to > work with > > Of course, the library would be unfriendly. > I just suggest there should be explicit way for the end-user to configure > enforce intention > rather than the spec trying to infer the intention from "root vs non-root". > > Here's another case: > Imagine I have a multi-project build. > Imagine I have a workable <dependencies> block somewhere in a submodule. > If I copy-paste the same <dependencies> to the root prroject, it might > accidentally break. > > Having different treatment for root and non-root POMS makes it harder to > move code (and its deps) between root and non-root modules. > > --- > > >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? > > Of course, there might be differences, however, let's focus on <version>. > We discuss only <version> in this thread, don't we? > Is there a true reason to have different meaning for <dependency><version> > tag in those cases? > > AFIAK, if I declare a dependency in Gradle, then the meaning of the version > would be the same no matter if > I produce the project or consume it or if I declare other dependencies side > by side. > With Gradle I can copy-paste dependencies block along with the code between > the root project and subprojects and > it would still work the same. > > Vladimir --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
