[jira] [Commented] (MNG-6420) ComparableVersion incorrectly parses certain version strings

["Ross Goldberg (Jira)" <ji...@apache.org>]

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

Ross Goldberg commented on MNG-6420:
------------------------------------

I started looking through my code and incorporating the changes to master since then.

I've also replaced Java 10 API usages with Java 8 API usages.

I'm currently still using Guava for its immutable collections, which I can change.

A few questions:
 # Do you use any immutable collections in your codebase? If so, please tell me what library you use, and I'll switch my code from Guava to that. If not, should I just use java.util.Collections.unmodifiable*(…) static methods to simulate immutable collections?
 # Here is an issue that has nothing to do with hyphens: ComparableVersionTest expects "2.0" < "2.0.a" < "2.0.0.a". That makes no sense to me. "2.0" == "2.0.0.0" & "2.0.a" == "2.0.a.0", so ComparableVersionTest expects "2.0.0.0" < "2.0.a.0" < "2.0.0.a", which is completely nonsensical  I would prefer an ordering like: "2.0.0.0" < "2.0.0.a" < "2.0.a.0".  What do you prefer?  The ["spec"|https://maven.apache.org/pom.html#Version_Order_Specification] says the following, which doesn't specify how to compare tokens with the same prefix when one token is numeric, and the other token is non-numeric:
{quote}The version order is the {{lexicographical order}} on this sequence of prefixed tokens, the shorter one padded with enough "null" values with matching prefix to have the same length as the longer one. Padded "null" values depend on the prefix of the other version: 0 for '.', "" for '-'. The prefixed token order is:
 * if the prefix is the same, then compare the token:
 ** Numeric tokens have the natural order.
 ** Non-numeric ("qualifiers") tokens have the alphabetical order, except for the following tokens which come first in this order:"{{alpha}}" < "{{beta}}" < "{{milestone}}" < "{{rc}}" = "{{cr}}" < "{{snapshot}}" < "" = "{{final}}" = "{{ga}}" < "{{sp}}"
 *** the "{{alpha}}", "{{beta}}" and "{{milestone}}" qualifiers can respectively be shortened to "a", "b" and "m" when directly followed by a number.
 * else "{{.qualifier}}" < "{{-qualifier}}" < "{{-number}}" < "{{.number}}"{quote}
There are multiple potential ways to fix this.  I imagine that the simplest one would be to rewrite that part of the spec as:
{quote}The version order is the {{lexicographical order}} on this sequence of prefixed tokens, the shorter one padded with enough "null" values with matching prefix to have the same length as the longer one. Padded "null" values depend on the prefix of the other version: 0 for '.', "" for '-'. To compare two prefixed tokens:
 * if their prefixes are the same, then compare the tokens using the following ordering:
"alpha" < "beta" < "milestone" < "rc" = "cr" < "snapshot" < "" = "release" = "final" = "ga" = 0 < "sp" < all other non-numeric qualifiers in alphabetical order < non-zero integers in natural order

 ** the "{{alpha}}", "{{beta}}" and "{{milestone}}" qualifiers can each respectively be shortened to "a", "b" and "m" when directly followed by a digit.
 * else {{.qualifier}} < {{-qualifier}} < {{-number}} < {{.number}}{quote}
 # Can ComparableVersion#parseVersion(String) eventually be removed?  It would be nice to make ComparableVersion immutable.
 # I imagine that my code should be faster than the existing code.  How do you run performance benchmarks?  Do you use jmh?  Do you have any performance tests / scripts I can use?

> ComparableVersion incorrectly parses certain version strings
> ------------------------------------------------------------
>
>                 Key: MNG-6420
>                 URL: https://issues.apache.org/jira/browse/MNG-6420
>             Project: Maven
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.5.3
>            Reporter: Ross Goldberg
>            Priority: Major
>             Fix For: wontfix-candidate
>
>
> For certain version strings, ComparableVersion doesn't follow the Maven version order spec (https://maven.apache.org/pom.html#Version_Order_Specification).
> To improve the code & fix the following bugs, I completely rewrote the version parser (using Java 10 & Google Guava 25.1).  It is attached & passes all of the tests from ComparableVersionTest.
> Bug 1:
>  
> java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar 1-0.3 1
>  
> Outputs:
>  
> 1. 1-0.3 == 1-0.3
>    1-0.3 == 1
> 2. 1 == 1
>  
> This probleem stems from:
>  
> [https://github.com/apache/maven/blob/b8c06e61ab73cd9e25a5b2c93d9e5077b2196751/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L295-L296]
>  
>  
>  
> Bug 2:
>  
> java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.5.3.jar 1-0-2 1-0.1
>  
> 1. 1-0-2 == 1-2
>    1-0-2 < 1-0.1
> 2. 1-0.1 == 1-0.1
>  
> This problem stems from retaining ListItems that, after normalization, have no children other than the subsequent ListItem.  Removing the unnecessary ListItem should fix this (i.e. remove the extraneous ListItem (named extraneous) from its parent ListItem (named parent), then add the only child of extraneous to parent).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)