[
https://issues.apache.org/jira/browse/MRESOLVER-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-345.
-------------------------------------
Resolution: Fixed
> Conflict resolution in verbose mode is sensitive to version ordering
> --------------------------------------------------------------------
>
> Key: MRESOLVER-345
> URL: https://issues.apache.org/jira/browse/MRESOLVER-345
> Project: Maven Resolver
> Issue Type: Bug
> Reporter: Tamas Cservenak
> Priority: Major
> Fix For: 1.9.8
>
>
> It all started with MENFORCER-426. In short, if we have layout of
> dependencies like this below (ranges are key here), *conflict resolution in
> verbose mode* will misbehave, is sensitive on version ordering in the "dirty
> tree" (collected graph, output of DependencyCollector).
> {noformat}
> A -> B -> C[1..2]
> \--> C[1..2] {noformat}
> (explained: A depends on B and C[1..2] range, and B depends on C[1..2] as
> well)
> As when "dirty tree" is being collected by DependencyCollector (and we have
> two, old DF and new BF), the ranges are turned into series of artifacts with
> versions discovered (by VersionRangeResolver), so the input above while
> collecting A from above would yield some tree like this (in this example
> {{some-group:c:jar}} has versions 1.0 and 2.0 ):
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile]
> +- some-group:c:jar:1.0 [compile]
> \- some-group:c:jar:2.0 [compile] {noformat}
> This "dirty tree" is then transformed using {{ConflictResolver}} into final
> graph. Conflict resolver in "normal" mode works OK and produces stable
> outputs, that is not sensitive to ordering, this is OK.
> But, conflict resolver supports so called "verbose" mode as well, mostly used
> to perform some "analysis" on graph (like for example "dependency
> convergence" is). Conflict resolver in "verbose" mode {*}is version ordering
> sensitive{*}.
> Conflict resolver in "verbose" mode would transform that dirty tree above
> into this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:1.0 [compile] (conflicts 2.0)
> \- some-group:c:jar:2.0 [compile] {noformat}
> And for analysis like "dependency convergence", this would mean *divergency
> is found* (error condition), as there are conflicts. But, if you look more
> closely on input "dirty tree", you can notice that {{b}} depends on {{c:2.0}}
> as well (as b depends on range {{{}[1,2]{}}}.
> Moreover, that dirty tree above is output of resolver standard DF collector.
> BF on the other hand, produces dirty tree like this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | +- some-group:c:jar:2.0 [compile]
> | \- some-group:c:jar:1.0 [compile]
> +- some-group:c:jar:2.0 [compile]
> \- some-group:c:jar:1.0 [compile] {noformat}
> (the order of c dependencies are sorted descending).
> In other words, DF produces tree with versions in order as discovered
> (essentially metadata based), the BF explicitly sorts versions in descending
> order (to maximize skipper effect, but that is BF internal detail).
> Same conflict resolver in "verbose" mode transforms BF dirty tree into this:
> {noformat}
> some-group:a:jar:1.0 [compile]
> +- some-group:b:jar:1.0 [compile]
> | \- some-group:c:jar:2.0 [compile]
> \- some-group:c:jar:2.0 [compile] {noformat}
> And in this case, {*}there is no divergence found{*}. Again, this is same
> input, but collected with DF and BF collectors, then applied conflict
> resolution, and once we have divergence, and once we have no divergence. The
> difference between two inputs is only the order of versions (produced from
> discovered versions that were resolved from metadata, but new BF explicitly
> sorts versions in descending order to better utilize it's own internals).
> Proper conflict resolver solution should be:
> * insensitive on version ordering
> * produce "stable" (same) output for same input (version order should not
> matter, and this is not only about DF vs BF)
> * Good to have: the "verbose" mode we currently have is half-assed, in a
> way, *it still removes nodes* from tree, and leaves one version (the first in
> order, this is the problem) that holds conflict information.
> * Better to have: We may want a "full" verbose mode, where {*}node
> selection/elimination and mediation is done{*}, but *no node was removed*
> graph still contains all the nodes, as that would give much more precise
> picture about dependencies, than like today, "randomly" (first) nodes marked
> for conflict, rest removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
