[MENFORCER-426] DependencyConvergence transitive dependencies with version range by slawekjaranowski · Pull Request #259 · apache/maven-enforcer (original) (raw)

marked this pull request as draft

March 20, 2023 23:35

cstamas added a commit to apache/maven-resolver that referenced this pull request

Mar 24, 2023

…ersion ordering (#271)

Our two collector implementations produce slightly different dirty trees when in transitive dependencies ranges are in use. The new BF produces (w/ and w/o skipper) produces this dirty tree:

menforcer426:aid:ext:1 compile
+- menforcer426:bid:ext:1 compile
|  +- menforcer426:cid:ext:3 compile
|  +- menforcer426:cid:ext:2 compile
|  \- menforcer426:cid:ext:1 compile
+- menforcer426:cid:ext:3 compile
+- menforcer426:cid:ext:2 compile
\- menforcer426:cid:ext:1 compile

The "old" DF produces this one:

menforcer426:aid:ext:1 compile
+- menforcer426:bid:ext:1 compile
|  +- menforcer426:cid:ext:1 compile
|  +- menforcer426:cid:ext:2 compile
|  \- menforcer426:cid:ext:3 compile
+- menforcer426:cid:ext:1 compile
+- menforcer426:cid:ext:2 compile
\- menforcer426:cid:ext:3 compile

Spot the difference: the two dirty trees are "semantically" (or content-wise?) equal/same, except for the artifact ordering, where there was a version range (collector in this case discovers available versions that "fits" range and created nodes for them, one for each version that lies within version constraint). DF collector relies and provides "metadata based" ordering (as metadata contained the versions), while BF explicitly sorts them in descending order (for internal optimization purposes). Point is, both dirty trees are ok.

But, Conflict resolver in verbose mode for two inputs above produces different outputs. For DF with "divergence found", while for BF "no divergence found" (correctly).

Overall changes in this PR:

• most are test and test related resources
• cosmetic changes like javadoc typos, adding override etc
• added reusable DependencyGraphDumper
• key changes are in ConflictResolver covered by ConflictResolverTest UT changes
• overall fix is to make ConflictResolver insensitive to input dirty tree version ordering, make sure output is same for "semantically" (or content-wise?) same inputs.

How tested this:

• built/installed this PR
• built maven-3.9.x with this resolver
• ran maven IT suite -- OK
• ran apache/maven-enforcer#259 w/ built maven (so fixed resolver is used). This PR contains only one reproducer IT that fails with any released Maven version -- OK w/ maven built as above.

Just realized how enforcer ITs are good source of inspiration for resolver use cases, so many if not all of new tests are actually inspired by enforcer ITs.

https://issues.apache.org/jira/browse/MRESOLVER-345

…rsion range

IT for ensure that DependencyConvergence with transitive dependencies with version range works correctly Root cause was fixed in Maven 3.9.2

slawekjaranowski changed the title[MENFORCER-426] Reproduce issue [MENFORCER-426] DependencyConvergence transitive dependencies with version range

May 19, 2023

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})