Le mer. 15 oct. 2025 à 18:51, Vladimir Sitnikov <[email protected]> a écrit :
> >Cause you change the resolution of thousands of existing pom and all their > >consumers? > > I understand the concern about ecosystem impact. My view is that the net > effect would be positive, > especially if MNG-7852 (aligning on the highest compatible version) lands > as well. > This is where I poped out semver and its concern but anything else is undesired there since it leads to not respecting the overrides (hierarchy) which is current strategy for very good reasons (once again what would you say if you request a coffee and get a tea?). > > Maven 4 already introduces the “consumer POM.” It seems reasonable to apply > improved resolution rules > (e.g., consider transitive <dependencyManagement> globally, and prefer the > highest version) for consumer POMs. > That gives a clean, forward-compatible path. > Consumer pom is model v4.0.0 and there is no good way to change that at scale for a project scope (which includes transitive poms), this is the whole point. Now assuming we do not care and for maven 4 we ignore the consumer pom and read the build pom where we can inject more metadata...you still have the same issue, sometimes you will want to respect transitive version, sometimes not. I do not see a single case you want a transitive (> level 1) dep to override what you do. > > For Maven 3, this could remain opt-in (extension or flag). For Maven 4, we > could default to the new behavior for consumer POMs > and keep a toggle for legacy builds if needed > Please do not do that for this feature, as mentionned multiple times it means you will never know if your pom can be consummed properly or not. This would make lib writer insane or just bypassing that feature, I prefer we do focus on the actual override capability and potentially a version convergence feature. > > Today, resolution can yield surprising downgrades when multiple modules > from the same family are present. > Surprising but deterministic and documented. Your proposal will be way more surprising cause it doesn't respect anymore the project, its overrides and can lead to the same since the depMgt can downgrade versions. > Even advanced users occasionally stumble on this in demos (example at > 1:58:07: https://youtu.be/2kooPqDguyw?t=7087 ). > Will always be when you have some magic and complex cases whatever you do, you add magic you make it worse IMHO. > > If a user truly needs a strict lower version, that’s inherently risky. > There is a common case since java cadence changed: java limitation. Using a parallel with your example: v2 became java >= 17 but project is still java 11, not that uncommon these days. > We can support it explicitly (e.g., a clear strict version intent), > rather than letting accidental downgrades happen implicitly. > So if the dep is explicit in a pom you ignore the depMgt...so basically you never use depMgt? 🤔 > > If there are specific POMs you believe would break under these rules, > could you share one concrete example (before/after tree)? That would help > us verify the impact. > Think I shared enough examples and once again, your project has these issues. Use the java version example adjusting it if you find it more obvious. > > Vladimir >
