[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806925#comment-17806925
]
David M. Lloyd commented on MRESOLVER-336:
------------------------------------------
There are many thousand artifacts already in the wild using qualifiers, both
standard and custom, so I think that ship has sailed. But in any event, the
version syntax must be well-defined for all allowed cases, otherwise it's not
really a syntax. The behavior should be completely predictable.
Many of these bug reports came from me trying to determine or establish the
"true" syntactic rules of Maven versions. The code disagrees with itself every
place it is implemented, and the developers also seem to disagree with one
another on what these rules should be. But based on feedback from developers on
this and other issues, I think the most generally-accepted rules when
considering spec intent, existing usage, and existing code are as follows:
* Versions should be compared by segment, from left to right, where each
segment is defined and ordered as follows (from earliest to latest):
** The qualifier "alpha" == "a" (but only when "a" is immediately followed by
a number)
** The qualifier "beta" == "b" (but only when "b" is immediately followed by a
number)
** The qualifier "milestone" = "m" (but only when "m" is immediately followed
by a number)
** The qualifier "rc" == "cr"
** The qualifier "snapshot"
** The empty string == the number zero == "ga" == "final" == "release" (I call
these "zero segments" down below)
** The qualifier "sp"
** Any "custom" qualifier (i.e. non-empty letter sequence) sorted
lexicographically per {{ROOT}} locale, ascending
** Any positive integer sorted numerically ascending
* Segments can be explicitly separated by a single {{.}} (dot) or {{-}}
(hyphen) (one proposal also included {{_}} (underscore) as a separator)
* All qualifiers (not just custom qualifiers) are interpreted as being
case-insensitive in terms of the {{ROOT}} locale (that is, "FINAL" is equal to
"final", not "fınal")
* A zero-width segment separator also exists between any two segments when one
of the two segments is a number of any kind (including 0) and the other is a
alphabetical qualifier of any kind (including special qualifiers)
* Finally, any version can be considered to have an infinite number of
invisible *trailing* "zero" segments, for the purposes of comparison (in other
words, "1" == "1.0.0.0.0.0.0.0.0....")
According to the above rules, I think that the example version I gave above
"0.0.0.ga.ga.foo" should *not* be equal to "foo" exactly as "0.0.1" should not
be equal to "1". It *should* be equal to "0.0.0.0.0.foo". The issue itself is
due to the {{ga}} qualifier being equal to zero *sometimes* but not other
times. This inconsistency is the problem and should be fixed as described above.
I don't think it is realistic to get all or even most Java devs to agree on one
version {*}scheme{*}. However I do think it is not only realistic but
*critical* that we all agree on one version {*}syntax{*}. And, I think the
above is it, more or less, since it seems to eliminate most (maybe all) of the
problem cases that I could find in existing artifacts.
> Unexpected handling of qualifiers in GenericVersionScheme
> ---------------------------------------------------------
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 1.9.5
> Reporter: David M. Lloyd
> Assignee: Tamas Cservenak
> Priority: Major
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
> 0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
> ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
