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.
