[MRESOLVER-334] Maven Resolver's GenericVersionScheme diverges from the spec

[jira-importer]

David M. Lloyd opened MRESOLVER-334 and commented

The specification for version resolution indicates these facts which disagree with the implementation in {}GenericVersionScheme{}:

• "The Maven coordinate is split in tokens between dots ('{}.{}'), hyphens ('{}-{}') and transitions between digits and characters." - in {}GenericVersion{}, the underscore ('{}_{}') is also treated as a separator.
• In the examples area, it says that while "{}1-sp.1{}" > "{}1-ga.1{}", at the same time "{}1-sp-1{}" < "{}1-ga-1{}" = "{}1-1{}" due to "trailing 'null' values at each hyphen". But in addition to being untrue in the actual implementation, this relation is clearly nonsensical because it would place sp before {}ga{}, which would have a tremendous negative impact on the existing artifact ecosystem if it were carried out in the implementation.
• Also in the example area, we have "{}1.foo{}" = "{}1-foo{}" < "{}1-1{}" < "{}1.1{}", whereas in practice it is (rightly) "{}1.foo{}" = "{}1-foo{}" < "{}1-1{}" = "{}1.1{}".

In my opinion all of these things are spec errors so I'd be happy to see the spec page be updated and this bug consequently closed as "out of date", especially since the implementation behavior has been in the wild for some time.

---

Affects: 1.9.5

Issue Links:

• MNG-5568 ComparableVersion's breaks contract for Comparable, in some edgecases the comparisons are not transitive

• MNG-6964 Maven version sorting is internally inconsistent

• MNG-7644 Fix version comparison where .X1 < -X2 for any string qualifier X

• MNG-7701 Incompatible version sorting changes

Remote Links:

• GitHub Pull Request #486
  

Backported to: 2.0.0-alpha-7

[jira-importer]

David M. Lloyd commented

Additionally, there is a provision in the specification which says that "if the prefix is the same.... '.qualifier' = '-qualifier' < '-number' < '.number'". However, I was not able to produce an example that showed the ordering "-number" < ".number".

[jira-importer]

Tamas Cservenak commented

Just adding some context to this issue:
Maven historically had the version parsing implemented in maven-artifact moduie https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java and AFAIR the site documents this class https://maven.apache.org/pom.html#version-order-specification
With Maven 3.x and introduction of aether/resolver, this logic was refined according to this page https://cwiki.apache.org/confluence/display/MAVEN//Versioning and implementation landed here https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/version/GenericVersion.java

In short, Maven has two version implementations (parser and comparison) and they deviate from each other annoyingly little, but they do.

One of our goals is to stop this happening, and rely on only one (resolver most probably), so maven-artifact code should be considered "deprecated", but alas, we cannot do that right now as many other stuff blocks us (like use of maven-artifact version related classes on maven-artifact Artifact and related classes...

Best would be if we could:

• settle on one (as this confuses not only us but also users)
• lay down proper doco/specs and fix all issues
• consider what can we do in Maven 3.x window

Note: Maven 4 API does not suffer from this as it introduces completely new API

[jira-importer]

Tamas Cservenak commented

The fix of this issue is not happening in Resolver codebase, but on Maven Site instead: apache/maven-site#486