[
https://issues.apache.org/jira/browse/MNG-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008075#comment-17008075
]
Ross Goldberg edited comment on MNG-6420 at 1/5/20 12:55 PM:
-------------------------------------------------------------
Thanks for the replies. I agree with you on all 3 points (though for #1, I
wouldn’t necessarily assign it to intent, but rather to the best option
available given the current wording of the spec, regardless of intent).
I would think that almost all people would be surprised that any ordering
scheme would consider 2.q < 2. I personally think that the spec & code should
be switched such that both result in 2 < 2.q, but maybe I’m missing something.
I don’t think that it would be hard to revise the spec to make it deterministic
for all cases, or to produce orderings that more closely align with what most
people would expect. I also don’t think any such revised spec would be long,
difficult to understand, or to implement. In fact, a revised spec should be
easier to understand & implement since it wouldn’t leave holes that force
people to divine its intent.
was (Author: xdr):
Thanks for the replies. I agree with you on all 3 points (though for #1, I
wouldn’t necessarily assign it to intent, but rather to the best option
available given the current wording of the spec, regardless of intent).
I would think that almost all people would be surprised that any ordering
scheme would consider 2.q < 2. I personally think that the spec & code should
be switched such that both result in 2 < 2.q, but maybe I’m missing something.
I don’t think it would be hard to revise the spec to make it deterministic for
all cases, or to produce orderings more closely align with what most people
would expect. I also don’t think any such revised spec would be long, difficult
to understand, or to implement. In fact, it’ll a revised spec should be easier
to understand & implement since it wouldn’t leave holes that force people to
divine its intent.
> 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, 3.6.3
> Reporter: Ross Goldberg
> Priority: Major
>
> For certain version strings, ComparableVersion doesn't follow the Maven
> version order spec
> (https://maven.apache.org/pom.html#Version_Order_Specification), and/or
> produces canonical versions that are incongruent with both the spec and the
> code's ordering.
> To improve the code & fix the following bugs, I completely rewrote the
> version parser (using Java 8). I will create a PR sometime soon.
> *Bug 1: comparison violates spec ordering*
>
> java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.6.3.jar
> 1-0.3 1
>
> Outputs:
>
> 1. 1-0.3 == 1-0.3
> 1-0.3 == 1
> 2. 1 == 1
>
> This problem 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: canonical incongruent with spec and code ordering*
>
> java -jar /usr/local/Cellar/maven/3.5.3/libexec/lib/maven-artifact-3.6.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)
