[jira] [Commented] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec

["Tamas Cservenak (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17704102#comment-17704102 ] 

Tamas Cservenak commented on MRESOLVER-334:
-------------------------------------------

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

> Maven Resolver's GenericVersionScheme diverges from the spec
> ------------------------------------------------------------
>
>                 Key: MRESOLVER-334
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-334
>             Project: Maven Resolver
>          Issue Type: Bug
>          Components: Resolver
>    Affects Versions: 1.9.5
>            Reporter: David M. Lloyd
>            Priority: Major
>
> The [specification for version resolution|https://maven.apache.org/pom.html#version-order-specification] 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.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)