>No, depends if another lib does the same and it is common to thave that >case for commons* as mentionned.
Please clarify exactly. I do not understand which "another lib" you mean. >Yes but still need the hack I mentionned, ie control the dependencies you >bring back, no transitive magic No. My suggestion does not need the hack you mention, and my suggestion makes the resolution automatic from the end user's point of view. >Also note that what you propose, ie to make it automagically work, is >literally to enforce end user to review any transitive pom to ensure what >happens in his pom is what he expected or understand it, sounds a time >killer, even with AI. Please clarify exactly where I propose that everybody should review all the poms to get the feature working. >change this order and the >resolution will defer a lot due to something you do not define yourself Please, do not mix "pom order" or "dependency declaration depth" here. I want to keep this proposal focused. Can we please focus on <dependencyManagement> in transitive deps here? >This is wrong, depends on multiple factors, it will be as often 1.0.0 as >1.1.0 >Without your suggestion too - as of today. Romain, Could you please execute the test I shared at GitHub? The current Maven **always** selects 1.0.0 in that example, and it never selects 1.1.0. Here's the link: https://github.com/vlsi/jarsplit?tab=readme-ov-file#maven-400-snapshot-8134db6f3c18ab2c68764a5ae05c9e08846b9787 >Can you confirm you assume semver and this is the key which makes it >working for you and that ultimately depMgt is totally unrelated to the >solution in terms of conflict resolution? Romain, I do not see how semver is connected with Maven resolution. semver has nothing to do here. Can you confirm Maven 4.0.0-SNAPSHOT resolves 1.0.0 and causes failures in the runtime? Vladimir
