Le 07/11/2025 à 15:33, Vladimir Sitnikov a écrit :
There's no progress since 2021
I was talking about https://github.com/apache/maven/issues/11391
But anyway, #11391 seems quite active now, which seems to me an
attractive resolution. The reason is that resolving a version conflict
requires an arbitrary decision, and each arbitrary decision satisfies
only a subset of the use cases. Maybe the proposal in this thread
satisfies a larger subset than the current Maven behavior, but other
criteria such as easy to understand/configure may also be preferred. In
such situation, I think that the most effective way to overcome
resistance from the community is to give control to users, which is my
understanding of #11391.
Going for a pluggable solutions for a common use case does not sound right
since it would make life of non-Maven consumers much harder.
This debate can be kept for later. I suggest to first make possible to
have different strategies, regardless the opinions about which strategy
is best, because otherwise it will be hard to convince everyone. Then
later, we can revisit which strategy should be the default.
In other words, if you suggest that published poms on Central would require
"resolution plugins",
then the tooling like IDE, non-Maven build systems would have to execute the
same plugins which would
be extremely hard to get workable.
But shouldn't the version conflict resolution strategy be chosen by
consumers of the POM rather than those who publish them?
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
