Le mer. 15 oct. 2025 à 08:04, Vladimir Sitnikov <[email protected]> a écrit :
> >add v2 as depMgt, it does resolve deps in v2 as written in my previous > mail > >but exec print 1.0.0 in your main so likely a bug in exec which doesn't > use > >the strict resolution of resolver > > It is not a bug in exec. The dependency:tree classpath is aligned with the > exec results. > Not sure how you conclude that, I shared the output showing it is not true (once you put libv2 first). > > Let me put it again: if lib-uses-v2 goes first, then maven resolves the > following jars on the classpath. > commons-compress-core-2.0.0.jar (it includes .core packages for 2.0.0) > commons-compress-tar-2.0.0.jar (it includes .tar packages for 2.0.0) > commons-compress-1.0.0.jar (it includes .core, .tar., and .xz packages for > 1.0.0) > > Note that "core" packages duplicate between commons-compress-core-2.0.0.jar > and commons-compress-1.0.0.jar. > This is exactly the "split package" issue as .core is split between two > jars. > Well just cause you do not have commons-compress-2.0.0 for the transition as it was explained before. Now if you want to replace it -> back to the replacement topic, not depMgt one. > > >Sure, just take your project, today you have 1.0.0, if we take depMgt in > >consideration by default and do your request it will break (also as > >mentionned this is not what does solve the issue). > > You say "just take a project and it will break", however, I don't see the > failure mode yet. > Please provide the concrete failure. > The fact you do not have the dependency you expect anymore will break in most cases at runtime. It is quite similar to your case except that today it is defined and works for everybody. > > >Please do not say that as if generally true, this is only true for a > >particular hello world case as explained before with the spark example for > >ex. > > Please acknowledge my proposal improves Maven in two cases I listed in the > very first mail. > "1. Version Alignment Across Related Modules" > "2. Simplified Migration Path for Library Modularization" > Not sure why you keep looping on that but as explained this is not true, this is solved already. You can say you do not like the syntax or whatever but this doesn't enable anything more. The 2 features which could are the replacement of gav and semver handling but this is very different. > > At no point in time I suggested that the proposal will fix all issues in > Maven. > If you still think the proposal will make "issues with spark" worse than > with current Maven, please provide the concrete failure mode. > > So far I provided several cases when the current Maven provides unworkable > app, and I explained how the proposal fixes those cases. > Can you acknowledge not a single one is not workable and all your cases are common and solved for years and that you just want a different syntax which only works in a ver low depth tree and no overlapping deps in depMgt case? > > Of course, the proposal would make the resolution more complicated, > however, there's no evidence that the resolution > result will be worse than the one of the current Maven. > ....got explained in multiple mails with examples, even your project is a good example it is broken by design > > Vladimir >
