>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. 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. >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. >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" 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. 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. Vladimir
