Hi Martin, Think the critical part is not how to resolve dependencies - we can @Named whatever strategy we want, make it pluggable from the outside etc... But how do you translate it reliably in the consumer pom since we do not want to flatten anymore and we'll not be able to say "ignore transitives". So means you make it work for you but not your consumers, is it worth it to split the ecosystem and create noise and such misleading issues in the community/ecosystem?
Think we can experiment with extensions and see the adoption before doing it in core Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 7 nov. 2025 à 11:18, Martin Desruisseaux <[email protected]> a écrit : > Hello Vladimir > > I have read the document and checkout the `jarsplit` demo project. I > have not done a deep analysis, but my superficial understanding is that > the issue could be considered as part of the classical problem of > dependency version conflict. It the particular case discussed in this > thread, the version conflict is caused by a JAR being split in many > JARs, but this cause does not need to be the focus of the discussion. > > I do not know if the current Maven 3 behavior is documented as the > standard Maven behavior. But documented or not, I would not said that it > is intuitive. At least on my side, especially when BOM imports are > involved. I tend to have an empirical approach: do my best for avoiding > conflicts, and when conflicts happen do try-and-error with the hope that > whatever seems to work will still okay in production, without really > understanding how conflicting versions have been resolved. > > What about the following strategy for Maven 4: > > * Build on top of Guillaume's "Configurable Dependency Version > Resolution Strategy" [1]. > * Bring to Maven core the part of Maven Enforcer Plugin that check > dependency convergence. > * Have dependency convergence as one of the resolution strategy of > [1], named maybe "strict". > * Current behavior would be another resolution strategy of [1]. > * If resolution strategy was not explicitly specified, print a warning > saying that "strict" will become the default in a future Maven version. > * Vladimir's proposal could be another resolution strategy. If [1] is > extensible, this resolution strategy could be done as a separated > experimental plugin. > > Martin > > [1]https://github.com/apache/maven/issues/11391 > > > Le 07/11/2025 à 10:18, Vladimir Sitnikov a écrit : > > I've created a document summarizing both the idea, and the comments: > > > https://docs.google.com/document/d/1svC1ab75MzlKYUqsOiWWLvUDc_DGbO2hhoULpM5CacY/edit?usp=sharing > > > > WDYT? > > > > Everybody could comment on the document. > > I would happily clarify the moot points if needed. >
