[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807288#comment-17807288
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
cstamas commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893909638
@dmlloyd General remarks:
* let's put aside `maven-artifact` (is to be killed off in Maven4, or
around). As we know, currently Maven _does suffer_ from existence of these
"parallel worlds" (two version parsing and sorting implementation, generally in
par, but only "generally"). Goal is to stop doing this, and have _one golden
implementation_ that does everything correctly. Current situation is a
maintenance nightmare. Hence, let's focus on `maven-resolver-util` versions
only.
* I tend to NOT modify existing UTs, not to redefine or introduce breaking
change needed to touch existing UTs, as that would lead to (most probable)
breakage in versions already out there in the wild.
* On the other hand, Maven4 is now prepared to support "alternate" version
schemes, as somewhat explained in the issue
https://issues.apache.org/jira/browse/MNG-7951. The goal would be to have
multiple Version implementations (those of Resolver' Version interface), maybe
like "legacy" (that implements `maven-artifact` one with all of it's known
flaws), then "generic" (this one), and probably in future new ones as well
("semver", "maven4" or whatever improved ones). Still, while doing these, we
need to keep eye on interoperability as well, as switching to totally new
scheme may really be possibly only in some isolated environment (ie. org that
uses ONLY deps with in-org defined versioning).
> 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)
