>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
