Le jeu. 6 nov. 2025 à 10:03, Vladimir Sitnikov <[email protected]> a écrit :
> >If you start having multiples you mess up consumers as explained cause the > >resolution looks random and unexpected for lib writers. > > Romain, please provide technical justification. > > What I suggest is an incremental feature that > 1) Keeps the same behavior for the old-style projects > 2) Enables **publishers** to make consumers' cases easier > Please check all cases, this will not be made easier most of the time, think about jackson in stacks/platforms. > 3) The similar feature is adopted by well-known tools in the industry > (junit, jackson since 2.12.0 released in 2020) > Exactly the example it stays a mess and needs manual fix. > > It is not fair to say "you mess up consumers as explained". > You have never provided even a single example where the added feature > would "mess up consumers". > ... you didn't read it but that's another concern also keep in mind you example shows that > > >Still not, you propose to break most users and make the lib writer life a > >nightmare in practise. > > Hey Romain, it is you who say "break users". At the same time you provide > no examples of the way their projects will break. > You do understand what you mean when you say "today it is broken", if you reverse it then you just break it the exact same way where it works today. Once again there the key is the hability to select the right version and it is NEVER from a transitive pom but from the list of transitive poms. This is where I spoke about semver as a common solution for that but which is undoable in java ecosystem today IMHO. But we could flag dependencies as being semver friendly and do something enhanced for such dependencies only. > > I do care about backward compatibility for existing projects, and my > suggestion does not break the apps. > please stop saying that, you change the dep -> you do break, that's simple and just real life, not theory. > It might be you confuse the threads > > >How would you solve the fact two libs using the same transitive lib use > >different strategies? > > Romain, are you sure this reply belongs to "Honor dependencyManagement in > intermediate POMs" thread? > Frankly, I have never suggested "per lib strategy" or "per artifact > strategy" here. > I suggest that Maven should honour <dependencyManagement> in transitive > POMs. > Yes, 2 depMgr entries covering the same scope. If it doesn't happen -> we are good today with boms and it is cleaner, if it happens you doesn't solve anything so at the end your solution is very limited in terms of use cases. > > Vladimir >
