Le mer. 15 oct. 2025 à 11:29, Vladimir Sitnikov <[email protected]> a écrit :
> >With your mode the end user writes in his pom "i want v1" and with your > >mechanism you do resolve v2 which doesn't have to be backward compat so > >there is no reason it works (and in practise it wouldn't with a lot of > > This still does not look like an example to me. > > Please explain how exactly Maven would resolve commons-compress to 2.0 with > my proposal implemented assuming 2.0 is not backward compatible. > What which exact piece of metadata (in which exact pom) would trick Maven > to bump commons-compress to 2.0? (assuming you mean 2.0 being incompatible > with 1.0) > Isn't it the whole point of you proposal? align dependencies with a data which is unrelated to the project? Whatever it does for commons-compress or other dep scope it leads to the same issues. > > Hint: if commons-compress **vendor** plans for dropping backward > compatibility, they would refrain from adding > <dependencyManagement>commons-compress:2.0.0 when releasing 2.0 > You bet but not what happens in real life and you must accept that people will create a depMgt fo commons-compress in project like "my config lib". DepMgt is not done nor used for your purpose so it can only lead to issues due to the number of pom on central until you toggle it as explained and if so you get the integration issue (a pom can't be integrated anymore). So long story short, depMgt will not be used transitively for dependencies since it breaks and doesnt solve any issue we already solved. I'll let you some days to play with it and see that enhancements can likely be at different level but you need to leave your hello world project which is too simplistic to realize it (ack that). > > Vladimir >
