[
https://issues.apache.org/jira/browse/MNG-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749174#comment-17749174
]
Vladimir Sitnikov commented on MNG-7852:
----------------------------------------
{quote} Best would be to move this discussion to ML instead{quote}
Would you please clarify why do you think the issue belongs to ML rather than
JIRA?
I do not understand the reason, and I do not want to get a "file JIRA instead"
response on the ML.
{quote}Also, you mix runtime and compile time things ("nobody ensure that
people can compile code")
{quote}
Correct me if I am wrong, but the full cite is "nobody ensures that people can
compile code with the recent version {*}and supply an old version in the
execution{*}". "and supply an old version in the execution" is important as
otherwise, the bug won't trigger.
Correct me if I am wrong, but Java requires compile code before one can proceed
with the execution, and it does matter which third-party libraries were present
on the compilation classpath as it affects the resulting bytecode.
My example says that projects rarely ensure their jars can be safely downgraded.
{quote} You should do your homework{quote}
Sure thing.
Would you please respond to
https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748173&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748173
or
https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748217&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748217
?
In my examples, the problematic transitive dependencies come from **other**
dependencies, and I do not use the problematic ones directly.
I do not understand which of them you suggest to "declare as direct".
If you suggest declaring all the possible transitive dependencies (including
transitives of transitives) as direct, then, well, the re-declaring
dependencies approach is prone to errors I described in
https://issues.apache.org/jira/browse/MNG-7852?focusedCommentId=17748677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17748677.
> Use all the versions for dependency resolution rather than "nearest first" or
> "declared first"
> ----------------------------------------------------------------------------------------------
>
> Key: MNG-7852
> URL: https://issues.apache.org/jira/browse/MNG-7852
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> Currently, Maven uses "nearest first", "declared first" rules for conflict
> resolution:
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
> I suggest those rules are removed since they produce hard to reason
> resolutions for transitive dependencies.
> Below I list reasons why both "nearest wins" and "declared first" yield
> hard-to-predict behaviours, and they are likely to produce dependency
> downgrades and the associated runtime errors.
> Here are some examples:
> 1) "Nearest first". Even though the rule sounds easy, it is not something the
> users can control. For instance, if the project does not use Guava library,
> some of the transitive dependencies could add a dependency on Guava. The user
> has no control which dependency would be "the nearest" to declare Guava, so
> user has literally no way to tell which Guava version will be used.
> The only workaround I see for the users is to declare Guava dependency
> explicitly even though the project does not need it directly. It sounds like
> Maven requires users to re-declare all the possible dependencies, including
> the runtime-only ones.
> 2) "declared first". Of course, dependency order matters for classpath order,
> however, it is not predictable in practice, and it might result in
> downgrading dependencies. Imagine the project does not use Guice. However,
> transitive dependencies might use Guice. At the same time, they might start
> using Guice and stop using Guice, so the user can never tell which will be
> the first project that uses Guice. Unfortunately, in Maven, the first project
> that declares dependency wins, so it might easily be the case that the first
> mention of Guice will reference outdated version that would be incompatible
> with the newer one required in another dependency.
> 3) Here's a real-life case: Maven downgrades protobuf-java dependency causing
> something like NoSuchMethodError at the runtime. The step to reproduce is to
> add dependency on dev.sigstore:sigstore-java:0.4.0. See [~hboutemy] analysis
> in https://github.com/hboutemy/sigstore-maven-plugin/blob/import/analysis.md
> Long story short, sigstore-java does not depend on protobuf-java directly,
> however, sigstore-java depends on several third-party libraries that
> eventually depend on protobuf-java. Maven's "the first wins" behaviour
> results in incoherent set of protobuf dependencies on the classpath.
> 4) see "unexpected" in MNG-5988
> To my best understanding, when it comes to transitive dependencies, both
> "nearest first" and "declared first" are random variables which user can't
> control unless they re-declare all the dependencies in their local pom. I
> suggest Maven should not use random variables like "dependency depth" or
> "dependency order" to drive conflict resolution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
