The spec also seems to not define the comparison output for when two tokens
have the same prefix, but one token is a qualifier, and the other is an
integer:
For such cases, the ComparableVersion code behaves oddly, in that it
outputs:
java -jar maven-artifact-3.5.3.jar 2 2.a
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 2 == 2
2 < 2.a
2. 2.a == 2.a
java -jar maven-artifact-3.5.3.jar 2.0.a 2.a
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 2.0.a == 2.0.a
2.0.a > 2.a
2. 2.a == 2.a
Why is:
2 == 2.0 == 2.0.0 < 2.a == 2.a.0 < 2.0.a
That doesn't make much sense to me. I would normally expect a to be
consistently higher than 0 (except for the special a<integer> alpha
replacement, which isn't apropos to this example):
2 == 2.0 == 2.0.0 < 2.0.a < 2.a == 2.a.0
If you must have 2.a.0 < 2.0.a, then I would expect a to consistently be
lower than 0:
2.a == 2.a.0 < 2.0.a < 2 == 2.0 == 2.0.0
I think you could obtain my preferred ordering by rewriting the "prefixed
token order" segment of the spec as the following (I haven't thought it
through completely, though, so there might be bugs):
- if the prefix is the same, then compare the tokens using the following
ordering scheme:
"alpha" < "beta" < "milestone" < "rc" = "cr" < "snapshot" < "" =
"final" = "ga" = 0 < "sp" < all other qualifiers in alphabetical order <
positive integers in natural order
the "alpha", "beta" and "milestone" qualifiers can respectively be
shortened to "a", "b" and "m" when directly followed by a number.
- else .qualifier < -token < .integer
In the above, you could elongate the last line to:
- else .qualifier < -qualifier < -integer < .integer
On Sat, Jun 2, 2018 at 11:37 AM, Ross Goldberg <[email protected]>
wrote:
> Sorry, the 1-0-2 == 1-2 induced me to read the < as a >.
>
> The code is buggy because it produces a canonical form & a comparison
> result that are inconsistent.
>
> The canonical form is consistent with the spec (as I read the spec; if you
> read it otherwise, please let me know).
>
> Everything should be consistent, otherwise, things will break & people
> won't know what to expect.
>
> e.g., ComparableVersion#equals(Object o) uses canonical.equals(((
> ComparableVersion) o).canonical). This breaks the Comparable contract,
> since:
>
> true == new ComparableVersion("1-0-2").equals(new ComparableVersion("1-2")
> )
>
> But:
>
> -1 == new ComparableVersion("1-0-2").compareTo(new ComparableVersi
> on("1-2"))
>
> Given that breaking the Comparable contract is bad, the code should
> probably be made consistent.
>
> If you modify the code, you might as well choose the outcome that would
> make the most sense to most people.
>
> Most people would expect the current ordering (1-0-2 < 1-1), but not the
> current canonical form for 1-0-2 (1-2).
>
> Therefore, it makes sense to me to change the canonical form and to keep
> the current ordering.
>
> If you do this, then the code will not reflect the spec (as I read the
> spec).
>
> I feel that my revised proposal aligns the spec with the current ordering.
>
> On Sat, Jun 2, 2018 at 4:59 AM, Hervé BOUTEMY <[email protected]>
> wrote:
>
>> no, current implementation result is 1-0-2 < 1-1
>>
>> here is the proof:
>> $ java -jar maven-artifact-3.5.3.jar 1-0-2 1-1
>> Display parameters as parsed by Maven (in canonical form) and comparison
>> result:
>> 1. 1-0-2 == 1-2
>> 1-0-2 < 1-1
>> 2. 1-1 == 1-1
>>
>>
>> then explanations: who uses dashes (-) instead of dots (.) as version
>> separator?
>> dash is not a normal version separator in Maven: it's used to as a
>> separator between version and qualifier
>> then 1-0-2 is something that we don't really understand: 1.0-2 or 1.0.2
>> would have a meaning, but not 1-0-2
>>
>> Then honestly, I won't even try to understand how we got to the
>> conclusion that 1-0-2 canonical representation is 1-2: I'd question people
>> who wrote 1-0-2 as version string
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 31 mai 2018, 16:22:18 CEST Ross Goldberg a écrit :
>> > The maven Maven version order spec (
>> > https://maven.apache.org/pom.html#Version_Order_Specification)
>> indicates
>> > that :
>> >
>> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
>> >
>> > That doesn't make much sense to me.
>> >
>> > I think the following line from the spec should be revised from:
>> >
>> > Then, starting from the end of the version, the trailing "null" values
>> (0,
>> > "", "final", "ga") are trimmed.
>> >
>> > To:
>> >
>> > Then, starting from the end of the version string, all trailing "null"
>> > qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
>> > tokens that do not immediately follow a hyphen prefix (regardless of
>> > whether the hyphen is explicit or implicit) are likewise trimmed.
>>
>
