[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807318#comment-17807318
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
dmlloyd commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894051838
> > What do you mean by "UT"? I will note that this spec, as it stands,
already changes several existing behaviors. I'd say that the best thing would
be to clarify and establish a global, simple, and context-free set of rules,
since breakage is inevitable, but at the same time, prefer behaviors that are
most consistent with what exists today.
>
> The maven-resolver codebase contains 47 tests (methods, with multiple
assertions) for `GenericVersion` (and some related, implicit ones in other
tests).
Oh, "UT" = unit tests. Got it.
> This PR does _not_ modifies any of existing tests and assertions, and they
all pass. Most of these tests were collected when Aether were implemented, and
Maven artifacts (produced by Maven2) were already out in the wild. Breaking any
of the existing tests should not happen and must be avoided. This PR merely
added new test cases, the "edge cases" and codifies some other cases (no
covered by existing ones).
I agree that this should be done to the maximum extent possible.
> Hence, IMHO this PR does _not_ change behaviour of version implementation,
at least not those behaviour that are codified as test assertions predating
this PR (and served the purpose of ensuring proper transition from Maven2 to
Maven3).
This is tricky though because the current implementation does have known
bugs which are (clearly) untested, and are maybe untestable, so it is
inevitable that some breakage *will* occur unless you simply clone the existing
implementation. For example `-` and `.` separators are definitely unequal
today, and `_` is not even a separator today AFACIT.
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.
> 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)
