[MRESOLVER-379] Problem when relocations and ranges are used in collection

[jira-importer]

Tamas Cservenak opened MRESOLVER-379 and commented

Affects both old DF and new BF collectors.
Example:

• A1 -> B[1,3]
• B1 relocated to C1
• B2 relocated to C2
• B3 relocated to C3

In this example, as output of collection dirty tree (verbose) I'd expect:

A1
+- C1
+- C2
+- C3

But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:

DF does this:

A1
+- C1

BF does this:

A1
+- C3

Cause is probably as BF "reverse sort" versions, but none will return proper range.

Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps itself" onto junit:junit versions.

---

Issue Links:

• MNG-3454 processing a relocation erases requested version range

[jira-importer]

wei cai commented

Tamas Cservenak 

Do you mean the verbose mode? If not in verbose mode, tree should just print out the winner

[jira-importer]

Tamas Cservenak commented

Yes, "dirty tree", the "verbose" output. I used this existing (and passing) UT as "template":
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegateTestSupport.java#L501
That produces for BF this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_BF.txt
While DF produce this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_DF.txt

Only difference between BF and DF is version ordering (which is okay, see fix MRESOLVER-345).

I basically copy-pasted this UT w/ data and created this UT:
#312

It reproduces the SOError on master, and on "fixed" branch makes BF behave as in this issue (that is somehow consistent with DF sans version selected)

[jira-importer]

Tamas Cservenak commented

Seems related, as it is exactly what happens it seems: MNG-3454
Note: this issue is Maven2, but Maven3/Resolver was done by strictly mimicking Maven2 behavior to lessen breakages and ease migration.

Based on issue, this can be considered as edge case and just have it documented?

[jira-importer]

wei cai commented

Tamas Cservenak 

If run mvn dependency:tree, both df & bf prints 

A1
+- C3 

Not quite get the issue, but the above behavior makes sense, user declare a dependency with version range, it actually means it would depend on one specific version, print all available versions is not necessary.

Probably typo in the comment? You actually mean with maven-resolver code, the dirty tree differs as below (which is expected as you mentioned):

DF

A1 
+- C1
+- C2
+- C3

BF

A1 
+- C3
+- C2
+- C1 

MNG-3454 is a bit different, it says a dependency was relocated another dependency with different version like A 1.0 -> B 2.0