[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807309#comment-17807309
]
ASF GitHub Bot commented on MRESOLVER-336:
------------------------------------------
cstamas commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894012288
> 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). 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).
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).
My goal with this PR (and existing "generic" implementation) is to lay down
spec and fix some corner cases to our best knowledge _without_ disturbing the
existing tests. Later, down the road, we may introduce a "new" Maven4 spec that
would introduce inevitable breakages maybe, but at the same time, would prefer
behaviors that are most consistent with what exists today.
> 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)
