>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. >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>? 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. 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. 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 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. >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. 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. 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. 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. >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). [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
