Le mar. 14 oct. 2025 à 08:57, Vladimir Sitnikov <[email protected]> a écrit :
> >Hmm, no cause this means you break all existing pom - and without spoiling > >we'll not rewrite all poms out there so best case you scope your feature > to > >your own poms. > > Romain, > Could you provide at least *one concrete example* of an existing POM that > would break? > I want to understand the failure mode you have in mind. > 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). > > >Yes, invert lib2 and lib1 in your pom and you get > > What exactly do you mean by “invert lib2 and lib1”? Do you mean: place > lib-uses-v2 before lib-uses-v1 in <dependencies>? > yes > If so, here is what I see: > > [INFO] [stdout] lib-uses-v1: > [INFO] [stdout] CoreVersion = 2.0.0 > [INFO] [stdout] TarCompressor = 2.0.0 > [INFO] [stdout] XzCompressor = 1.0.0 > [INFO] [stdout] lib-uses-v2: > [INFO] [stdout] CoreVersion = 2.0.0 > [INFO] [stdout] TarCompressor = 2.0.0 > > Note XzCompressor = 1.0.0. That is precisely the version misalignment > across related modules I described in my first email. > Piotr mentioned [1] that alignment would be useful for log4j as well. > scope=import is done for that in one project of the hierarchy so import the bom of libv2 and be it > > Yes, reordering can sometimes make the app start, but it can also produce > an untested combination (e.g., core-2.0.0 + tar-2.0.0 + xz-1.0.0) > and even split packages when core-1.x and core-2.x land together. > Sure but you said it was backward compatible so it works > > With the proposal to honor transitive <dependencyManagement> globally, > Maven would consistently converge to 2.0.0 for all commons-compress-* > modules regardless of declaration order; and the split-packages risk goes > away because 1.x jars don’t end up on the classpath. > If globally == transitively this is just not true (only when you have no overlapping between depMgt which is rare) > > >if you have your project importing spark and commons-compress, both will > >define in their dep commons-compress with different versions, how do you > >resolve it? > > For the classpath we ultimately produce, I believe Maven should converge on > a single version for each GAV. > Whether that should be “highest” or “nearest” is tracked in MNG-7852 [2] / > issue#9070 [3], and we can discuss that policy separately. > Even without changing that policy, honoring transitive dependencyManagement > still provides clear benefits: > it aligns versions within a family of modules the producer intended to move > together. > And it creates yet another level of conflicts with new strategy (more complex) to put in place cause you have the scope import which is highly underdefined > > >the resolution is already automatic, it is not the one you want but it is > >defined and doesn't have more pitfalls than your proposal > > Romain, > Today Maven 4-SNAPSHOT frequently ends up with 1.0.0 on the classpath in my > example, which leads to runtime failures. > As Tamas mentionned, this is true because this is what you did explicitly configured. > The suggestion to honor transitive dependencyManagement would converge the > related commons-compress-* modules to > 2.0.0 (as published by the producer) and avoid those failures without > consumers hand-crafting excludes/re-adds. > 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. Pleae have a look to gradle conflict resolution strategy, they are quite close to maven ones except substitution which is the replace topic I mentionned at the beginning of the thread ( https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html ). > > If you see additional pitfalls with this approach, could you *point them > out specifically*? > > >Exactly but it *would* be the only way to make maven selecting > 1.0.0 > >instead of 1.0.0 when 1.0.0 and 1.1.0 are selected > > Maven already has a deterministic version comparison (see [4]); this > proposal does not require semver or bytecode analysis. > To use v2 when you explicitly state i want to use v1 it does. > It simply says: when computing the single classpath, Maven may also > consider transitive <dependencyManagement> > published by artifacts already in the graph, so related modules align to > the versions the producer declared. > The only depMgt you have is for commons-compress which is the deepest dep in your tree so it is likely you hit another dep at a higher level defining commons-compress:v1.whatever and there you are back to standard dep resolution so you didn't solve your issue in real projects if you did but you did breaks projects relying on the fact we do not use that. So if we do for hello world projects like your sample we need a toggle to enable it from your project pom and here are the two issues: * we already have a toggle: define the deps * the combination of poms will be a mess in the ecosystem cause nobody will test all cases so the best practise will be to flatten poms and never use depMgt which goes against your request IMHO If you take into account transitive depMgt it must be for the tree subscope only (otherwise it is promotion and is highly inconsistent by design) and in your project case it will just be used for compress-core not for all other deps. Now if you want to go with promotion it literally means you say to explicit user overrides "you are dumb, let's do something else that what you requested", do you think it is sane? Just think to somebody who uses compress-core 2 through a lib of lib then downgrade it to v1 cause there is a bug (was not compress but a real life example) then you just say "no no, use the bug and breaks your app". We must always respect what the user requests. > > >side note: exec resolution can differ from dependency plugin (and other > >plugins) and there can make you assume wrong things for the build: > > Neither exec output nor dependency:tree shows xz:2.0.0 in the failing case, > which suggests this is resolver behavior, > not a plugin view. If you have a better end-user-facing way to verify the > effective resolution, > I’m happy to use it; please suggest the exact command(s). > 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 (for good and bad reasons - good=it has some custom config about the ~classpath, bad=likely missed) > > [1] https://lists.apache.org/thread/z5vqbh75nsl03sy26xtrxh3fwv1h2kn7 > [2] https://issues.apache.org/jira/browse/MNG-7852 > [3] https://github.com/apache/maven/issues/9070 > [4] https://maven.apache.org/pom.html#Version_Order_Specification > > Vladimir >
