[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807330#comment-17807330
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
dmlloyd commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894094290
> > So having "preserve existing UTs" as the metric of success is a bit of
sophistry IMO. In the end you are breaking some things but not others. But the
things you are _not_ breaking are not guided by any particular principle other
than "preserve the UTs". This seems fine on the surface but I don't think it's
a good guiding principle. I think context-free parsability is a better
principle, because that will protect you from bugs down the line while breaking
almost nothing in practice. UTs _may_ tell you what is going to break, but only
if you expand them to cover things that are not currently covered today.
> > In other words, the inadequacy of the pre-existing unit tests really
robs this criteria of any useful meaning. It may give some emotional comfort,
but any practical guarantee of compatibility as a result is pure fiction.
Better to embrace the fact that things will break, and try to come up with
rules which minimize the _actual_ breakage while preferring real-world cases
whenever possible. Maybe with a test corpus of some or all of the versions
found in central.
>
> I agree here. And that's what I tried to (probably badly) explain, that
"generic" scheme should be fixed as much as possible (or viable), and simply
leave it as is. We both most probably want to introduce a new scheme, as you
explain, that should be used with Maven4 as default. This new scheme, along
with kill off of the "parallel implementation" in `maven-artifact` will
hopefully lead to "law and order" when it comes to version parsing and
ordering. Legacy is legacy, and is there to stay, while Maven4 allows us to fix
issues like these. Even if the "new" scheme behaves 90% as existing "generic"
one, but the remaining 10% can make a difference.
OK I see, so you only want to describe here what is exactly already
happening in `maven-resolver`, without change. The source of my confusion is
the expectation that the purpose was to *update* the spec, and then the
behavior, of this existing implementation in some way in preparation for Maven
4, so that's why I was alarmed :)
With all that said, I think this clarification makes a lot of sense and I'll
give it one more non-technical look-over focusing on presentation and content.
> 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)
