Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
lprimak commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1893295331 > create a huge headache for all downstream users of this, who use the ASF parent POM to build multi-module snapshots I also want to reiterate that multi-module projects would not be affected at all. Only multi-repository ones that are not using Apache Jenkins -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Upgrade to Maven 4.0.0-alpha-12 [maven-plugin-testing]
gnodet commented on code in PR #39:
URL:
https://github.com/apache/maven-plugin-testing/pull/39#discussion_r1453106042
##
maven-plugin-testing-harness/pom.xml:
##
@@ -74,6 +80,15 @@ under the License.
${mavenVersion}
provided
+
+ org.apache.maven
+ maven-xml-impl
+ ${mavenVersion}
Review Comment:
Is that necessary ? We're running unit tests here, this is not a dependency
of a plugin which runs in Maven. Having this dependency optional or provided
means that all plugins will have to add a dependency to it in order to execute
their unit tests, isn't it ?
I wonder if we should split this library in two separate modules, one for
Maven 3 and another one for Maven 4.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
kwin commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1893308232 Local builds are affected, GitHub actions are affected (everything which does not use a centrally managed `settings.xml` with that repo in it), so yes from my perspective the impact is big. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Upgrade to Maven 4.0.0-alpha-12 [maven-plugin-testing]
gnodet commented on code in PR #39:
URL:
https://github.com/apache/maven-plugin-testing/pull/39#discussion_r1453116900
##
maven-plugin-testing-harness/pom.xml:
##
@@ -74,6 +80,15 @@ under the License.
${mavenVersion}
provided
+
+ org.apache.maven
+ maven-xml-impl
+ ${mavenVersion}
Review Comment:
I've removed the dependency which is not actually used here. I'll send an
email to the dev list about moving some modules around.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MPOM-453] Disable annotation processing by compiler [maven-parent]
slawekjaranowski commented on PR #157: URL: https://github.com/apache/maven-parent/pull/157#issuecomment-1893332054 I need more tests ... like possibility to override -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MPOM-451] Remove repository elements from Apache Parent [maven-apache-parent]
lprimak commented on PR #183: URL: https://github.com/apache/maven-apache-parent/pull/183#issuecomment-1893341924 > Local builds are affected Not sure how. Usually local builds are either multi-module or 'installed' and do not use snapshot repository anyway. GH actions don't use snapshot repository either. Do you have an example project in mind that you think would be affected? How many do you think? Is this a guess or do you have some concrete idea of how many project? and which ones? I'd be happy to help fix any issues that would arise. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin merged PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MPOM-264.
--
Fix Version/s: ASF-32
Resolution: Fixed
Fixed in
https://github.com/apache/maven-apache-parent/commit/b938653652022a5754d7398168d3f897e55228af.
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: ASF-32
>
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas opened a new pull request, #406: URL: https://github.com/apache/maven-resolver/pull/406 Fix code and extend UT coverage --- https://issues.apache.org/jira/browse/MRESOLVER-336 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807175#comment-17807175
]
Tamas Cservenak commented on MRESOLVER-336:
---
[~dmlloyd] please review and comment, also will add to package-info the spec
(adapting your text) to serve as "ultimate ref" (as other pages on Maven Site
may get outdated).
> 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)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807173#comment-17807173
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas opened a new pull request, #406:
URL: https://github.com/apache/maven-resolver/pull/406
Fix code and extend UT coverage
---
https://issues.apache.org/jira/browse/MRESOLVER-336
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
michael-o commented on PR #406: URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893471235 What is the motivation behind this? Just refinement? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807176#comment-17807176
]
ASF GitHub Bot commented on MRESOLVER-336:
--
michael-o commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893471235
What is the motivation behind this? Just refinement?
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on PR #406: URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893473553 Grand motivation is to "clear up and have spec fully laid down", along with fixing some nasty edge cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807178#comment-17807178
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893473553
Grand motivation is to "clear up and have spec fully laid down", along with
fixing some nasty edge cases.
> 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)
[jira] [Comment Edited] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807175#comment-17807175
]
Tamas Cservenak edited comment on MRESOLVER-336 at 1/16/24 11:17 AM:
-
[~dmlloyd] please review and comment PR
https://github.com/apache/maven-resolver/pull/406
The spec in package javadoc is to serve as "ultimate ref" (as other pages on
Maven Site may get outdated).
was (Author: cstamas):
[~dmlloyd] please review and comment, also will add to package-info the spec
(adapting your text) to serve as "ultimate ref" (as other pages on Maven Site
may get outdated).
> 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)
[jira] [Created] (MWRAPPER-122) Mingw paths problem on Windows
Krystian Panek created MWRAPPER-122:
---
Summary: Mingw paths problem on Windows
Key: MWRAPPER-122
URL: https://issues.apache.org/jira/browse/MWRAPPER-122
Project: Maven Wrapper
Issue Type: Bug
Reporter: Krystian Panek
When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
only on Windows in GitBash (on Mac and Linux works without problems) the
following command is executed (I just replaced the last "exec" statement with
"echo" to troubleshoot):
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
Note that {*}bad path separators are generated{*}.
To fix the problem I needed to update the code:
{code:java}
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then{code}
to the following:
{code:java}
# For Cygwin or Mingw, switch paths to Windows format before running java
if [ "$cygwin" ] || [ "$mingw" ]; then{code}
then I have a working exec command generated:
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
/c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
It would be nice to make the "mvnw script work in more use cases. by
introducing the fix like the above or similar making my integration work
without problems.
Greetings, Krystian
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MWRAPPER-122) Mingw paths problem on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystian Panek updated MWRAPPER-122:
Description:
When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
only on Windows in GitBash (on Mac and Linux works without problems) the
following command is executed (I just replaced the last "exec" statement with
"echo" to troubleshoot):
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
Note that *bad path separators are generated* and my task execution results in
an error:
{code:java}
task: [aem:build:root] sh mvnw clean install -N && mkdir -p target && touch
target/done.txt
Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.wrapper.MavenWrapperMain
task: Failed to run task "aem:build:root": exit status 1{code}
To fix the problem I needed to update the code:
{code:java}
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then{code}
to the following:
{code:java}
# For Cygwin or Mingw, switch paths to Windows format before running java
if [ "$cygwin" ] || [ "$mingw" ]; then{code}
then I have a working exec command generated:
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
/c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
It would be nice to make the "mvnw script work in more use cases. by
introducing the fix like the above or similar making my integration work
without problems.
Greetings, Krystian
was:
When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
only on Windows in GitBash (on Mac and Linux works without problems) the
following command is executed (I just replaced the last "exec" statement with
"echo" to troubleshoot):
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
Note that {*}bad path separators are generated{*}.
To fix the problem I needed to update the code:
{code:java}
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then{code}
to the following:
{code:java}
# For Cygwin or Mingw, switch paths to Windows format before running java
if [ "$cygwin" ] || [ "$mingw" ]; then{code}
then I have a working exec command generated:
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
/c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
It would be nice to make the "mvnw script work in more use cases. by
introducing the fix like the above or similar making my integration work
without problems.
Greetings, Krystian
> Mingw paths problem on Windows
> --
>
> Key: MWRAPPER-122
> URL: https://issues.apache.org/jira/browse/MWRAPPER-122
> Project: Maven Wrapper
> Issue Type: Bug
>Reporter: Krystian Panek
>Priority: Major
>
> When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
> only on Windows in GitBash (on Mac and Linux works without problems) the
> following command is executed (I just replaced the last "exec" statement with
> "echo" to troubleshoot):
> {code:java}
> /c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
> C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
> -Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
> org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
> Note that *bad path separators are generated* and my task execution results
> in an error:
> {code:java}
> task: [aem:build:root] sh mvnw clean install -N && mkdir -p target && touch
> target/done.txt
> Error: Could not find or load main class
> org.apache.maven.wrapper.MavenWrapperMain
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.wrapper.MavenWrapperMain
> task: Failed to run task "aem:build:root": exit status 1{code}
> To fix the problem I needed to update the code:
> {code:java}
> # For Cygwin, switch paths to Windows format b
[jira] [Commented] (MWRAPPER-122) Mingw paths problem on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807200#comment-17807200
]
Michael Osipov commented on MWRAPPER-122:
-
Does this happen in the actual {{mvn}} script as well?
> Mingw paths problem on Windows
> --
>
> Key: MWRAPPER-122
> URL: https://issues.apache.org/jira/browse/MWRAPPER-122
> Project: Maven Wrapper
> Issue Type: Bug
>Reporter: Krystian Panek
>Priority: Major
>
> When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
> only on Windows in GitBash (on Mac and Linux works without problems) the
> following command is executed (I just replaced the last "exec" statement with
> "echo" to troubleshoot):
> {code:java}
> /c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
> C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
> -Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
> org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
> Note that *bad path separators are generated* and my task execution results
> in an error:
> {code:java}
> task: [aem:build:root] sh mvnw clean install -N && mkdir -p target && touch
> target/done.txt
> Error: Could not find or load main class
> org.apache.maven.wrapper.MavenWrapperMain
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.wrapper.MavenWrapperMain
> task: Failed to run task "aem:build:root": exit status 1{code}
> To fix the problem I needed to update the code:
> {code:java}
> # For Cygwin, switch paths to Windows format before running java
> if $cygwin; then{code}
> to the following:
> {code:java}
> # For Cygwin or Mingw, switch paths to Windows format before running java
> if [ "$cygwin" ] || [ "$mingw" ]; then{code}
> then I have a working exec command generated:
> {code:java}
> /c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
> /c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
> -Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
> org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
> It would be nice to make the "mvnw script work in more use cases. by
> introducing the fix like the above or similar making my integration work
> without problems.
>
> Greetings, Krystian
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807218#comment-17807218 ] Michael Osipov edited comment on DOXIA-725 at 1/16/24 12:26 PM: [~Abel S.Romero], no offense taken. One of the problems with a BOM that most of them stack,so have to go through all releases and do a BOM with a separate project of which you need only fraction. I am not completely sure how much better the BOM would be...This is, though, something we should consider after all of the changes have been done. was (Author: michael-o): [~Abel S.Romero], no offense taken. One of the problems with a BOM that most of them stack,so have to go through all releases and do a BOM with a separate project of which you need only fraction. I am not completely sure how much better the BOM would be... > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MNG-6399] Lift JDK minimum to JDK 8 [maven]
turbanoff opened a new pull request, #1382: URL: https://github.com/apache/maven/pull/1382 Update README.txt in 3.9 branch to mention that Java 8 is required. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6399) Lift JDK minimum to JDK 8
[ https://issues.apache.org/jira/browse/MNG-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807220#comment-17807220 ] ASF GitHub Bot commented on MNG-6399: - turbanoff opened a new pull request, #1382: URL: https://github.com/apache/maven/pull/1382 Update README.txt in 3.9 branch to mention that Java 8 is required. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ > Lift JDK minimum to JDK 8 > - > > Key: MNG-6399 > URL: https://issues.apache.org/jira/browse/MNG-6399 > Project: Maven > Issue Type: Task >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0 > > Attachments: maven-3.9.6-zip-content.png > > > I would like to lift the minimum of Maven Core to JDK 8 (I think it's time).. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-570) Javadoc: Add link to javac references from JDK17
Konrad Windszus created MCOMPILER-570:
-
Summary: Javadoc: Add link to javac references from JDK17
Key: MCOMPILER-570
URL: https://issues.apache.org/jira/browse/MCOMPILER-570
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Konrad Windszus
Similar to what was done in MJAVADOC-729 all plugin parameters which are more
or less passed as is to the underlying {{javac}} tool should have a link in
their javadoc to the according Oracle documentation for javac from JDK17
(https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html).
Although it depends a bit on the underlying compiler being used, the most
common combination is with
https://codehaus-plexus.github.io/plexus-compiler/plexus-compilers/plexus-compiler-javac/
which either calls {{javac}} via commandline or via
{{com.sun.tools.javac.Main}} which share the same semantics for the arguments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807264#comment-17807264
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453482466
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
+ * In comparison, a "zero segment" separator also exists between any
two segments when one of them is numeric segment (including 0) and the other is
non-numeric segment (including qualifiers).
Review Comment:
Is this saying that if I have "foo123" that it is canonically equal to
"foo.0.123"? If not, then maybe the phrase "implicit separator" is better than
saying "'zero segment' separator".
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step,
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453482466
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
+ * In comparison, a "zero segment" separator also exists between any
two segments when one of them is numeric segment (including 0) and the other is
non-numeric segment (including qualifiers).
Review Comment:
Is this saying that if I have "foo123" that it is canonically equal to
"foo.0.123"? If not, then maybe the phrase "implicit separator" is better than
saying "'zero segment' separator".
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"},
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807271#comment-17807271 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks a lot for the explanations. Regardless, the original topic is resolved and the other issue I had with maven-site seems to be related to locale configuration (I need to dig deeper). This can be closed. I agree we can see how the changes evolve. Thanks again! > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453530630
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Also note that today it seems that qualifiers also come before integers, so
maybe this revised ordering which is both internally consistent and largely
compatible with what exists today:
> * `max`
> * qualifiers in order
> * `alpha`/`a`
> * `beta`/`b`
> * `milestone`/`m`
> * `rc`/`cr`
> * `snapshot`
> * positive integers (numerically)
> * zero segment
> * empty string
> * `final`/`ga`/`release`
> * zero
> * qualifiers in order
> * `sp`
> * other strings (lexicographically)
> * `min`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807275#comment-17807275
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453530630
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Also note that today it seems that qualifiers also come before integers, so
maybe this revised ordering which is both internally consistent and largely
compatible with what exists today:
> * `max`
> * qualifiers in order
> * `alpha`/`a`
> * `beta`/`b`
> * `milestone`/`m`
> * `rc`/`cr`
> * `snapshot`
> * positive integers (numerically)
> * zero segment
> * empty string
> * `final`/`ga`/`release`
> * zero
> * qualifiers in order
> * `sp`
> * other strings (lexicographically)
> * `min`
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering in all cases:
* `max`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* positive integers (numerically)
* other strings (lexicographically)
* `min`
Note that the existing order of qualifiers vs other strings seems to be
opposite of what is given here.
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they repre
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807276#comment-17807276
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering in all cases:
* `max`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* positive integers (numerically)
* other strings (lexicographically)
* `min`
Note that the existing order of qualifiers vs other strings seems to be
opposite of what is given here.
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "s
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807279#comment-17807279
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering (lowest to highest) in all cases:
* `min`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* other strings (lexicographically)
* positive integers (numerically)
* `max`
Note that the existing order of qualifiers vs other strings seems to be
opposite of what is given here.
> 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 th
[jira] [Commented] (MWRAPPER-122) Mingw paths problem on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807280#comment-17807280
]
Krystian Panek commented on MWRAPPER-122:
-
just calling
{code:java}
sh mvnw --version{code}
works but when the same is called through taskfile does not.
I checked that in both cases "uname" returns "Linux" so pretty strange.
> Mingw paths problem on Windows
> --
>
> Key: MWRAPPER-122
> URL: https://issues.apache.org/jira/browse/MWRAPPER-122
> Project: Maven Wrapper
> Issue Type: Bug
>Reporter: Krystian Panek
>Priority: Major
>
> When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
> only on Windows in GitBash (on Mac and Linux works without problems) the
> following command is executed (I just replaced the last "exec" statement with
> "echo" to troubleshoot):
> {code:java}
> /c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
> C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
> -Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
> org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
> Note that *bad path separators are generated* and my task execution results
> in an error:
> {code:java}
> task: [aem:build:root] sh mvnw clean install -N && mkdir -p target && touch
> target/done.txt
> Error: Could not find or load main class
> org.apache.maven.wrapper.MavenWrapperMain
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.wrapper.MavenWrapperMain
> task: Failed to run task "aem:build:root": exit status 1{code}
> To fix the problem I needed to update the code:
> {code:java}
> # For Cygwin, switch paths to Windows format before running java
> if $cygwin; then{code}
> to the following:
> {code:java}
> # For Cygwin or Mingw, switch paths to Windows format before running java
> if [ "$cygwin" ] || [ "$mingw" ]; then{code}
> then I have a working exec command generated:
> {code:java}
> /c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
> /c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
> -Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
> org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
> It would be nice to make the "mvnw script work in more use cases. by
> introducing the fix like the above or similar making my integration work
> without problems.
>
> Greetings, Krystian
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering (lowest to highest) in all cases:
* `min`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* other strings (lexicographically)
* positive integers (numerically)
* `max`
Note that the existing order of qualifiers vs other strings seems to be
opposite of what is given here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MWRAPPER-122) Mingw paths problem on Windows
[
https://issues.apache.org/jira/browse/MWRAPPER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystian Panek updated MWRAPPER-122:
Description:
When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
only on Windows in GitBash (on Mac and Linux works without problems) the
following command is executed (I just replaced the last "exec" statement with
"echo" to troubleshoot):
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
Note that *bad path separators are generated* and my task execution results in
an error:
{code:java}
task: [aem:build:root] sh mvnw clean install -N && mkdir -p target && touch
target/done.txt
Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.wrapper.MavenWrapperMain
task: Failed to run task "aem:build:root": exit status 1{code}
To fix the problem I needed to update the code:
{code:java}
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then{code}
to the following:
{code:java}
# For Cygwin or Mingw, switch paths to Windows format before running java
if [ "$cygwin" = true ] || [ "$mingw" = true ]; then{code}
then I have a working exec command generated:
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
/c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
It would be nice to make the "mvnw script work in more use cases. by
introducing the fix like the above or similar making my integration work
without problems.
Greetings, Krystian
was:
When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
only on Windows in GitBash (on Mac and Linux works without problems) the
following command is executed (I just replaced the last "exec" statement with
"echo" to troubleshoot):
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
Note that *bad path separators are generated* and my task execution results in
an error:
{code:java}
task: [aem:build:root] sh mvnw clean install -N && mkdir -p target && touch
target/done.txt
Error: Could not find or load main class
org.apache.maven.wrapper.MavenWrapperMain
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.wrapper.MavenWrapperMain
task: Failed to run task "aem:build:root": exit status 1{code}
To fix the problem I needed to update the code:
{code:java}
# For Cygwin, switch paths to Windows format before running java
if $cygwin; then{code}
to the following:
{code:java}
# For Cygwin or Mingw, switch paths to Windows format before running java
if [ "$cygwin" ] || [ "$mingw" ]; then{code}
then I have a working exec command generated:
{code:java}
/c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
/c/Projects/acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
-Dmaven.multiModuleProjectDirectory=/c/Projects/acme-aem-acme-mono-ad86003b367a
org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
It would be nice to make the "mvnw script work in more use cases. by
introducing the fix like the above or similar making my integration work
without problems.
Greetings, Krystian
> Mingw paths problem on Windows
> --
>
> Key: MWRAPPER-122
> URL: https://issues.apache.org/jira/browse/MWRAPPER-122
> Project: Maven Wrapper
> Issue Type: Bug
>Reporter: Krystian Panek
>Priority: Major
>
> When I call the Maven wrapper from [Taskfile.dev|https://taskfile.dev/] then
> only on Windows in GitBash (on Mac and Linux works without problems) the
> following command is executed (I just replaced the last "exec" statement with
> "echo" to troubleshoot):
> {code:java}
> /c/Program Files/Eclipse Adoptium/jdk-11.0.14.101-hotspot/bin/java -classpath
> C:\Projects\acme-aem-acme-mono-ad86003b367a/.mvn/wrapper/maven-wrapper.jar
> -Dmaven.multiModuleProjectDirectory=C:\Projects\acme-aem-acme-mono-ad86003b367a
> org.apache.maven.wrapper.MavenWrapperMain clean install -N{code}
> Note that *bad path separators are generated* and my task execution results
> in an error:
> {code:java}
> task: [aem:build:root] sh mvnw clean install -N && mkdir -p
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering (lowest to highest) in all cases:
* `min`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* other strings (lexicographically)
* positive integers (numerically)
* `max`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807285#comment-17807285
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453479693
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Why would these qualifiers not *always* be zero segments? For example I
could have `1.0.final.1`; if I then decided to have `1.0.1.final` I'd be more
likely to expect it to come later than `1.0.final.1` than to have it come
before. And having context-sensitive rules is problematic for parsing IMO; it's
better if two segments can always be compared in complete isolation than for it
to depend on what comes before or after it. I'd use this absolute segment
ordering (lowest to highest) in all cases:
* `min`
* qualifiers in order
* `alpha`/`a`
* `beta`/`b`
* `milestone`/`m`
* `rc`/`cr`
* `snapshot`
* zero segment
* empty string
* `final`/`ga`/`release`
* zero
* qualifiers in order
* `sp`
* other strings (lexicographically)
* positive integers (numerically)
* `max`
> 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
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
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).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
Konrad Windszus created DOXIATOOLS-82: - Summary: Update to Doxia 2.0.0-M9 Key: DOXIATOOLS-82 URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 Project: Maven Doxia Tools Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIATOOLS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIATOOLS-82: -- Component/s: Doxia Converter > Update to Doxia 2.0.0-M9 > > > Key: DOXIATOOLS-82 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Affects Versions: doxia-converter-1.3 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIATOOLS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIATOOLS-82: -- Affects Version/s: doxia-converter-1.3 > Update to Doxia 2.0.0-M9 > > > Key: DOXIATOOLS-82 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 > Project: Maven Doxia Tools > Issue Type: Improvement >Affects Versions: doxia-converter-1.3 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453549202
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
+}
+
+@Test
+void testEdgeCase_2_1() {
+assertOrder(X_GT_Y, "0.foo.1.2.3", "foo.1.2.3");
+// they were equal in Resolver 1.x
+assertOrder(X_GT_Y, "0.foo", "foo");
+assertOrder(X_EQ_Y, "1.0.0-foo", "1-foo");
+// but "foo" != "ga" (string > qualifier)
+assertOrder(X_LT_Y, "1.0.0-ga-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0-ga-foo", "1-ga-foo");
+assertOrder(X_LT_Y, "1.0.0.final-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0.final-foo", "1-final-foo");
+}
+
+@Test
+void testEdgeCase_2_2() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+Version v3 = newVersion("0.0.0.0.0.foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+// they were equal in Resolver 1.x
+assertNotEquals(v2, v3);
+// but "0" != "ga"
+assertNotEquals(v1, v3);
+}
+
+@Test
+void testEdge
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807289#comment-17807289
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453549202
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
+}
+
+@Test
+void testEdgeCase_2_1() {
+assertOrder(X_GT_Y, "0.foo.1.2.3", "foo.1.2.3");
+// they were equal in Resolver 1.x
+assertOrder(X_GT_Y, "0.foo", "foo");
+assertOrder(X_EQ_Y, "1.0.0-foo", "1-foo");
+// but "foo" != "ga" (string > qualifier)
+assertOrder(X_LT_Y, "1.0.0-ga-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0-ga-foo", "1-ga-foo");
+assertOrder(X_LT_Y, "1.0.0.final-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0.final-foo", "1-final-foo");
+}
+
+@Test
+void testEdgeCase_2_2() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+Version v3 = newVersion("0.0.0.0.0
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453555024
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
Today, it's the opposite. It also would be opposite of `ga`==`0` in all
cases as I proposed elsewhere.
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807290#comment-17807290
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453555024
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
Today, it's the opposite. It also would be opposite of `ga`==`0` in all
cases as I proposed elsewhere.
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(Gen
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453560220
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
+ * In comparison, a "zero segment" separator also exists between any
two segments when one of them is numeric segment (including 0) and the other is
non-numeric segment (including qualifiers).
Review Comment:
I would completely leave off this sentence actually, as we state above that
"transition" is implicit separator. Hence `foo123` is becoming `foo`, `123` (as
segments).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIATOOLS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807292#comment-17807292 ] ASF GitHub Bot commented on DOXIATOOLS-82: -- kwin opened a new pull request, #62: URL: https://github.com/apache/maven-doxia-converter/pull/62 Update commons-io and plexus-utils to match version from Doxia > Update to Doxia 2.0.0-M9 > > > Key: DOXIATOOLS-82 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Affects Versions: doxia-converter-1.3 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807294#comment-17807294
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453560220
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
+ * In comparison, a "zero segment" separator also exists between any
two segments when one of them is numeric segment (including 0) and the other is
non-numeric segment (including qualifiers).
Review Comment:
I would completely leave off this sentence actually, as we state above that
"transition" is implicit separator. Hence `foo123` is becoming `foo`, `123` (as
segments).
> 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)
Re: [PR] Bump doxiaVersion from 2.0.0-M6 to 2.0.0-M9 [maven-doxia-converter]
kwin closed pull request #61: Bump doxiaVersion from 2.0.0-M6 to 2.0.0-M9 URL: https://github.com/apache/maven-doxia-converter/pull/61 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump doxiaVersion from 2.0.0-M6 to 2.0.0-M9 [maven-doxia-converter]
dependabot[bot] commented on PR #61: URL: https://github.com/apache/maven-doxia-converter/pull/61#issuecomment-1893937957 OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump doxiaVersion from 2.0.0-M6 to 2.0.0-M9 [maven-doxia-converter]
kwin commented on PR #61: URL: https://github.com/apache/maven-doxia-converter/pull/61#issuecomment-1893937875 Superseded by #62. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIATOOLS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIATOOLS-82: -- Description: Changes in M7: https://issues.apache.org/jira/projects/DOXIA/versions/12353309 Changes in M8: https://issues.apache.org/jira/projects/DOXIA/versions/12353657 Changes in M9: https://issues.apache.org/jira/projects/DOXIA/versions/12354052 > Update to Doxia 2.0.0-M9 > > > Key: DOXIATOOLS-82 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Affects Versions: doxia-converter-1.3 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Changes in M7: https://issues.apache.org/jira/projects/DOXIA/versions/12353309 > Changes in M8: > https://issues.apache.org/jira/projects/DOXIA/versions/12353657 > Changes in M9: https://issues.apache.org/jira/projects/DOXIA/versions/12354052 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIATOOLS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved DOXIATOOLS-82. --- Fix Version/s: doxia-converter-1.4 Resolution: Fixed Fixed in https://github.com/apache/maven-doxia-converter/commit/c9503357138741fbc64788fd4b7aeee7560177de. > Update to Doxia 2.0.0-M9 > > > Key: DOXIATOOLS-82 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Affects Versions: doxia-converter-1.3 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: doxia-converter-1.4 > > > Changes in M7: https://issues.apache.org/jira/projects/DOXIA/versions/12353309 > Changes in M8: > https://issues.apache.org/jira/projects/DOXIA/versions/12353657 > Changes in M9: https://issues.apache.org/jira/projects/DOXIA/versions/12354052 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIATOOLS-82) Update to Doxia 2.0.0-M9
[ https://issues.apache.org/jira/browse/DOXIATOOLS-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807297#comment-17807297 ] ASF GitHub Bot commented on DOXIATOOLS-82: -- kwin merged PR #62: URL: https://github.com/apache/maven-doxia-converter/pull/62 > Update to Doxia 2.0.0-M9 > > > Key: DOXIATOOLS-82 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-82 > Project: Maven Doxia Tools > Issue Type: Improvement > Components: Doxia Converter >Affects Versions: doxia-converter-1.3 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Changes in M7: https://issues.apache.org/jira/projects/DOXIA/versions/12353309 > Changes in M8: > https://issues.apache.org/jira/projects/DOXIA/versions/12353657 > Changes in M9: https://issues.apache.org/jira/projects/DOXIA/versions/12354052 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [DOXIATOOLS-82] Update to Doxia 2.0.0-M9 [maven-doxia-converter]
kwin merged PR #62: URL: https://github.com/apache/maven-doxia-converter/pull/62 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on PR #406: URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893948794 > @dmlloyd General remarks: > > * let's put aside `maven-artifact` (is to be killed off in Maven4, or around). Fair enough :+1: > * 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. 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. > * 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 (technically: different schemes per maven session). I don't know if this will be a good thing or a bad thing. Probably both :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807299#comment-17807299
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1893948794
> @dmlloyd General remarks:
>
> * let's put aside `maven-artifact` (is to be killed off in Maven4, or
around).
Fair enough :+1:
> * 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.
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.
> * 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 (technically: different schemes
per maven session).
I don't know if this will be a good thing or a bad thing. Probably both :)
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453625285
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
+}
+
+@Test
+void testEdgeCase_2_1() {
+assertOrder(X_GT_Y, "0.foo.1.2.3", "foo.1.2.3");
+// they were equal in Resolver 1.x
+assertOrder(X_GT_Y, "0.foo", "foo");
+assertOrder(X_EQ_Y, "1.0.0-foo", "1-foo");
+// but "foo" != "ga" (string > qualifier)
+assertOrder(X_LT_Y, "1.0.0-ga-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0-ga-foo", "1-ga-foo");
+assertOrder(X_LT_Y, "1.0.0.final-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0.final-foo", "1-final-foo");
+}
+
+@Test
+void testEdgeCase_2_2() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+Version v3 = newVersion("0.0.0.0.0.foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+// they were equal in Resolver 1.x
+assertNotEquals(v2, v3);
+// but "0" != "ga"
+assertNotEquals(v1, v3);
+}
+
+@Test
+void testEdge
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807310#comment-17807310
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453625285
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
+}
+
+@Test
+void testEdgeCase_2_1() {
+assertOrder(X_GT_Y, "0.foo.1.2.3", "foo.1.2.3");
+// they were equal in Resolver 1.x
+assertOrder(X_GT_Y, "0.foo", "foo");
+assertOrder(X_EQ_Y, "1.0.0-foo", "1-foo");
+// but "foo" != "ga" (string > qualifier)
+assertOrder(X_LT_Y, "1.0.0-ga-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0-ga-foo", "1-ga-foo");
+assertOrder(X_LT_Y, "1.0.0.final-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0.final-foo", "1-final-foo");
+}
+
+@Test
+void testEdgeCase_2_2() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+Version v3 = newVersion("0.0.0.0.0
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453635292
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
As noted on JIRA, after discussing with teammates, we consider this
undefined (more than undocumented). In short, it is very uncommon and atypical
to start version with qualifier. I myself consider this example stretched.
Also, "ga" is not and must not be considered as a "replacement for" or
"alternative to" of "0". One is qualifier other is number. The "0" `ga`
qualifier carries serves the purpose of inter-qualifier comparison, not as
"number value".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807313#comment-17807313
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453635292
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
As noted on JIRA, after discussing with teammates, we consider this
undefined (more than undocumented). In short, it is very uncommon and atypical
to start version with qualifier. I myself consider this example stretched.
Also, "ga" is not and must not be considered as a "replacement for" or
"alternative to" of "0". One is qualifier other is number. The "0" `ga`
qualifier carries serves the purpose of inter-qualifier comparison, not as
"number value".
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
>
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453635292
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
As noted on JIRA, after discussing with teammates, we consider this
undefined (more than undocumented). In short, it is very uncommon and atypical
to start version with qualifier. I myself consider this example stretched.
Also, "ga" is not and must not be considered as a "replacement for" or
"alternative to" of "0". One is qualifier other is number. The "0" value
carried by `ga` qualifier serves the purpose of inter-qualifier comparison, not
as "number value".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807314#comment-17807314
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453635292
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
As noted on JIRA, after discussing with teammates, we consider this
undefined (more than undocumented). In short, it is very uncommon and atypical
to start version with qualifier. I myself consider this example stretched.
Also, "ga" is not and must not be considered as a "replacement for" or
"alternative to" of "0". One is qualifier other is number. The "0" value
carried by `ga` qualifier serves the purpose of inter-qualifier comparison, not
as "number value".
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453641518
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
And is not opposite, here is a test with 1.9.18 of Resolver:
```
[cstamas@angeleyes maven-resolver (MRESOLVER-336)]$ jbang
--main=org.eclipse.aether.util.version.GenericVersionScheme
org.apache.maven.resolver:maven-resolver-util:1.9.18 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]
[cstamas@angeleyes maven-resolver (MRESOLVER-336)]$
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807316#comment-17807316
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453641518
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
And is not opposite, here is a test with 1.9.18 of Resolver:
```
[cstamas@angeleyes maven-resolver (MRESOLVER-336)]$ jbang
--main=org.eclipse.aether.util.version.GenericVersionScheme
org.apache.maven.resolver:maven-resolver-util:1.9.18 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]
[cstamas@angeleyes maven-resolver (MRESOLVER-336)]$
```
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-33
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453647185
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Unsure what the problem is, but your example works as you expect, see
e160be1f8021e6092f20b118325590f316067be4
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
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)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807319#comment-17807319
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453647185
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Unsure what the problem is, but your example works as you expect, see
e160be1f8021e6092f20b118325590f316067be4
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453648141
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
+ * In comparison, a "zero segment" separator also exists between any
two segments when one of them is numeric segment (including 0) and the other is
non-numeric segment (including qualifiers).
Review Comment:
Removed
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807320#comment-17807320
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453648141
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
+ * In comparison, a "zero segment" separator also exists between any
two segments when one of them is numeric segment (including 0) and the other is
non-numeric segment (including qualifiers).
Review Comment:
Removed
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453656904
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
OK right, I think I was confused by the order that things are listed in the
spec (last to first). A better way of stating this is that having `1.0` and
`1.final` be equal is expected, but having `1.0-1` and `1.final-1` *not* be
equal would be unexpected. I think it very likely that nobody today relies on
this distinction, and thus it would be a good opportunity to establish the
universality of "zero segments".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807324#comment-17807324
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453656904
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
OK right, I think I was confused by the order that things are listed in the
spec (last to first). A better way of stating this is that having `1.0` and
`1.final` be equal is expected, but having `1.0-1` and `1.final-1` *not* be
equal would be unexpected. I think it very likely that nobody today relies on
this distinction, and thus it would be a good opportunity to establish the
universality of "zero segments".
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on PR #406: URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894068765 > > > 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. > > > > 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 AFAICT. > > 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807327#comment-17807327
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894068765
> > > 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.
> >
> >
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 AFAICT.
>
> 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.
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453502911
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
Review Comment:
~Today, according to both `maven-artifact` and `maven-resolver`, strings
come *after* qualifiers (at least in every situation I could think up)~.
I just tested this backwards, that's all. Maven Resolver seems to agree with
this ordering - when segments are tested alone. However, the order is
completely different if the segment is not trailing. I get this total order:
`numeric > min > max > string > qualifier`; I guess `min` and `max` lose
their special meaning when not trailing, though they shouldn't (for example I
might want to test with `1.min.max` or something like that). So again I think
it would be a good idea to make this context-free.
Other than that, this total order does make sense to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807328#comment-17807328
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453502911
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
Review Comment:
~Today, according to both `maven-artifact` and `maven-resolver`, strings
come *after* qualifiers (at least in every situation I could think up)~.
I just tested this backwards, that's all. Maven Resolver seems to agree with
this ordering - when segments are tested alone. However, the order is
completely different if the segment is not trailing. I get this total order:
`numeric > min > max > string > qualifier`; I guess `min` and `max` lose
their special meaning when not trailing, though they shouldn't (for example I
might want to test with `1.min.max` or something like that). So again I think
it would be a good idea to make this context-free.
Other than that, this total order does make sense to me.
> 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 "z
[jira] [Created] (DOXIATOOLS-83) jar-with-dependencies.jar has incomplete plexus/sisu metadata
Konrad Windszus created DOXIATOOLS-83:
-
Summary: jar-with-dependencies.jar has incomplete plexus/sisu
metadata
Key: DOXIATOOLS-83
URL: https://issues.apache.org/jira/browse/DOXIATOOLS-83
Project: Maven Doxia Tools
Issue Type: Bug
Affects Versions: doxia-converter-1.3
Reporter: Konrad Windszus
Assignee: Konrad Windszus
The converter creates an uber-jar with
https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies.
That has incomplete Sisu metadata in {{META-INF/sisu/javax.inject.Named}}
because multiple dependency jars contain that file. In the resulting jar only
the one from {{doxia-core}} is contained (as no merging happens).
In addition there is a redundant plexus/components.xml maintained at
https://github.com/apache/maven-doxia-converter/blob/master/src/main/resources/META-INF/plexus/components.xml
which contains outdated info.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIATOOLS-83) jar-with-dependencies.jar has incomplete Plexus/Sisu metadata
[
https://issues.apache.org/jira/browse/DOXIATOOLS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIATOOLS-83:
--
Summary: jar-with-dependencies.jar has incomplete Plexus/Sisu metadata
(was: jar-with-dependencies.jar has incomplete plexus/sisu metadata)
> jar-with-dependencies.jar has incomplete Plexus/Sisu metadata
> -
>
> Key: DOXIATOOLS-83
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-83
> Project: Maven Doxia Tools
> Issue Type: Bug
>Affects Versions: doxia-converter-1.3
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The converter creates an uber-jar with
> https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies.
> That has incomplete Sisu metadata in {{META-INF/sisu/javax.inject.Named}}
> because multiple dependency jars contain that file. In the resulting jar only
> the one from {{doxia-core}} is contained (as no merging happens).
> In addition there is a redundant plexus/components.xml maintained at
> https://github.com/apache/maven-doxia-converter/blob/master/src/main/resources/META-INF/plexus/components.xml
> which contains outdated info.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453671982
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Again, I have a feeling we are drifting away in a sense... If one given
project releases `1.0-1` and subsequently `1.final-1` I'd say they are not
consistent in their versioning. People/projects usually have (or agree on)
"version format" and stick to that. There are atypical cases like you brought
up (starting with qualifier) but in real life I don't think anybody uses
versions like that. Similarly, "sorting" (ordering) of versions happens usually
within same GA, so "same project", hence same "version format" can be assumed.
Maven never sorts (wildly different) versions from Maven Central... nor is
meant to support use case like that.
What I want to say, that we can and will probably find countless examples of
"what if..." versions, but we should really limit ourselves to real examples.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807329#comment-17807329
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453671982
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Again, I have a feeling we are drifting away in a sense... If one given
project releases `1.0-1` and subsequently `1.final-1` I'd say they are not
consistent in their versioning. People/projects usually have (or agree on)
"version format" and stick to that. There are atypical cases like you brought
up (starting with qualifier) but in real life I don't think anybody uses
versions like that. Similarly, "sorting" (ordering) of versions happens usually
within same GA, so "same project", hence same "version format" can be assumed.
Maven never sorts (wildly different) versions from Maven Central... nor is
meant to support use case like that.
What I want to say, that we can and will probably find countless examples of
"what if..." versions, but we should really limit ourselves to real examples.
> 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}
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453502911
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
Review Comment:
~Today, according to both `maven-artifact` and `maven-resolver`, strings
come *after* qualifiers (at least in every situation I could think up)~.
I just tested this backwards, that's all. Maven Resolver seems to agree with
this ordering - when segments are tested alone. However, the order is
completely different if the segment is not trailing. I get this total order:
`numeric > min > max > string > qualifier`; I guess `min` and `max` lose
their special meaning when not trailing, though they shouldn't (for example I
might want to test with `1.min.max` or something like that). So again I think
it would be a good idea to make this context-free *in a future implementation*.
Other than that, this total order does make sense to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807332#comment-17807332
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453502911
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
+ * In comparison of same kind segments, the given type of segment
determines comparison rules.
+ * In comparison of different kind of segments, following applies:
{@code max > numeric > string > qualifier > min}.
Review Comment:
~Today, according to both `maven-artifact` and `maven-resolver`, strings
come *after* qualifiers (at least in every situation I could think up)~.
I just tested this backwards, that's all. Maven Resolver seems to agree with
this ordering - when segments are tested alone. However, the order is
completely different if the segment is not trailing. I get this total order:
`numeric > min > max > string > qualifier`; I guess `min` and `max` lose
their special meaning when not trailing, though they shouldn't (for example I
might want to test with `1.min.max` or something like that). So again I think
it would be a good idea to make this context-free *in a future implementation*.
Other than that, this total order does make sense to me.
> 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]
> {co
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453678801
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Got it, I misinterpreted the goal of this change so I was getting worried
about potential breaking changes versus better/clearer behaviors. But as we're
not updating behaviors, I'm fine with this description as it stands.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807331#comment-17807331
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453678801
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,38 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
+ * There are two special segments, {@code "min"} and {@code "max"},
they represent absolute minimum and absolute maximum in comparisons.
+ * As last step, trailing "zero segments" are trimmed. Similarly,
"zero segments" positioned before numeric and non-numeric transitions (either
explicitly or implicitly delimited) are trimmed.
+ * When trimming, "zero segments" are qualifiers {@code "ga"}, {@code
"final"}, {@code "release"} only if being last (right-most) segment, empty
string and "0" always.
Review Comment:
Got it, I misinterpreted the goal of this change so I was getting worried
about potential breaking changes versus better/clearer behaviors. But as we're
not updating behaviors, I'm fine with this description as it stands.
> 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)
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453682391
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
You're right, I accidentally tested this with `maven-artifact` (because it
was in my `bash` history). My bad!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807333#comment-17807333
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453682391
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
Review Comment:
You're right, I accidentally tested this with `maven-artifact` (because it
was in my `bash` history). My bad!
> 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
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453684237
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
+}
+
+@Test
+void testEdgeCase_2_1() {
+assertOrder(X_GT_Y, "0.foo.1.2.3", "foo.1.2.3");
+// they were equal in Resolver 1.x
+assertOrder(X_GT_Y, "0.foo", "foo");
+assertOrder(X_EQ_Y, "1.0.0-foo", "1-foo");
+// but "foo" != "ga" (string > qualifier)
+assertOrder(X_LT_Y, "1.0.0-ga-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0-ga-foo", "1-ga-foo");
+assertOrder(X_LT_Y, "1.0.0.final-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0.final-foo", "1-final-foo");
+}
+
+@Test
+void testEdgeCase_2_2() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+Version v3 = newVersion("0.0.0.0.0.foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+// they were equal in Resolver 1.x
+assertNotEquals(v2, v3);
+// but "0" != "ga"
+assertNotEquals(v1, v3);
+}
+
+@Test
+void testEdge
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807335#comment-17807335
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453684237
##
maven-resolver-util/src/test/java/org/eclipse/aether/util/version/GenericVersionTest.java:
##
@@ -44,6 +41,155 @@ void testEmptyVersion() {
assertOrder(X_EQ_Y, "0", "");
}
+// Block of tests from https://issues.apache.org/jira/browse/MRESOLVER-336
+@Test
+void testTrimPadding() {
+// 1.0.0 -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0)));
+assertEquals(3, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNotNeededString() {
+// 1.0.0.string -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string")));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifier() {
+// 1.0.0.ga -> 1
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(4, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(1, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixed() {
+// 1.0.0.string.0.ga -> 1.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(6, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(2, items.size());
+}
+
+@Test
+void testTrimPaddingNeededQualifierMixedInBetweenGa() {
+// 1.0.ga.0.string.0.ga -> 1.ga.0.string
+List items = new ArrayList<>(Arrays.asList(
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 1),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_STRING,
"string"),
+new GenericVersion.Item(GenericVersion.Item.KIND_INT, 0),
+new GenericVersion.Item(GenericVersion.Item.KIND_QUALIFIER,
0)));
+assertEquals(7, items.size());
+GenericVersion.trimPadding(items);
+assertEquals(4, items.size());
+}
+
+@Test
+void testEdgeCase_1_1() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+// they were equal in Resolver 1.x
+assertNotEquals(v1, v2);
+}
+
+@Test
+void testEdgeCase_1_2() {
+// as expected
+assertOrder(X_LT_Y, "ga.ga.foo", "foo");
+}
+
+@Test
+void testEdgeCase_2_1() {
+assertOrder(X_GT_Y, "0.foo.1.2.3", "foo.1.2.3");
+// they were equal in Resolver 1.x
+assertOrder(X_GT_Y, "0.foo", "foo");
+assertOrder(X_EQ_Y, "1.0.0-foo", "1-foo");
+// but "foo" != "ga" (string > qualifier)
+assertOrder(X_LT_Y, "1.0.0-ga-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0-ga-foo", "1-ga-foo");
+assertOrder(X_LT_Y, "1.0.0.final-foo", "1-foo");
+assertOrder(X_EQ_Y, "1.0.0.final-foo", "1-final-foo");
+}
+
+@Test
+void testEdgeCase_2_2() {
+Version v1 = newVersion("0.0.0.ga.ga.foo");
+Version v2 = newVersion("foo");
+Version v3 = newVersion("0.0.0.0.0
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453690031
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,37 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
Review Comment:
Though it is mentioned above, maybe it's better to say:
```suggestion
* String segments are sorted lexicographically and
case-insensitively per ROOT locale, ascending.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807338#comment-17807338
]
ASF GitHub Bot commented on MRESOLVER-336:
--
dmlloyd commented on code in PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#discussion_r1453690031
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/version/package-info.java:
##
@@ -25,5 +25,37 @@
*
* On the other hand, the {@link
org.eclipse.aether.util.version.UnionVersionRange} is universal implementation
of
* "unions" of various {@link org.eclipse.aether.version.VersionRange}
instances.
+ *
+ * Generic Version Spec
+ * Version string is parsed into version according to these rules below:
+ *
+ * The version string is parsed into segments, from left to right.
+ * Segments are explicitly delimited by single {@code "." (dot)},
{@code "-" (hyphen)} or {@code "_" (underscore)} character.
+ * Segments are implicitly delimited by transition between digits and
non-digits.
+ * Segments are classified as numeric, string, qualifiers (special
case of string) and min/max.
+ * Numeric segments are sorted numerically, ascending.
+ * Non-numeric segments may be qualifiers (predefined) or strings
(non-empty letter sequence). All of them are interpreted as being
case-insensitive in terms of the ROOT locale.
+ * Qualifier segments (strings listed below) and their sort order
(ascending) are:
+ *
+ * "alpha" (== "a" when immediately followed by number)
+ * "beta" (== "b" when immediately followed by number)
+ * "milestone" (== "m" when immediately followed by
number)
+ * "rc" == "cr" (use of "cr" is discouraged)
+ * "snapshot"
+ * "ga" == "final" == "release"
+ * "sp"
+ *
+ *
+ * String segments are sorted lexicographically, per ROOT locale,
ascending.
Review Comment:
Though it is mentioned above, maybe it's better to say:
```suggestion
* String segments are sorted lexicographically and
case-insensitively per ROOT locale, ascending.
```
> 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)
Re: [PR] Improve transfer listener speed [maven]
gnodet closed pull request #1302: Improve transfer listener speed URL: https://github.com/apache/maven/pull/1302 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIATOOLS-83) jar-with-dependencies.jar has incomplete Plexus/Sisu metadata
[
https://issues.apache.org/jira/browse/DOXIATOOLS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807344#comment-17807344
]
ASF GitHub Bot commented on DOXIATOOLS-83:
--
kwin opened a new pull request, #63:
URL: https://github.com/apache/maven-doxia-converter/pull/63
This fixes incomplete/redundant Plexus/Sisu metadata
> jar-with-dependencies.jar has incomplete Plexus/Sisu metadata
> -
>
> Key: DOXIATOOLS-83
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-83
> Project: Maven Doxia Tools
> Issue Type: Bug
>Affects Versions: doxia-converter-1.3
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The converter creates an uber-jar with
> https://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies.
> That has incomplete Sisu metadata in {{META-INF/sisu/javax.inject.Named}}
> because multiple dependency jars contain that file. In the resulting jar only
> the one from {{doxia-core}} is contained (as no merging happens).
> In addition there is a redundant plexus/components.xml maintained at
> https://github.com/apache/maven-doxia-converter/blob/master/src/main/resources/META-INF/plexus/components.xml
> which contains outdated info.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [DOXIATOOLS-83] Build uber-jar with m-shade-p [maven-doxia-converter]
kwin opened a new pull request, #63: URL: https://github.com/apache/maven-doxia-converter/pull/63 This fixes incomplete/redundant Plexus/Sisu metadata -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MRESOLVER-336] Fixes to generic schema [maven-resolver]
cstamas commented on PR #406: URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894156931 @dmlloyd one last commit, just to doco your findings as well, and warn users doing "atypical" things, that they may be burned in future :smile: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807352#comment-17807352
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894156931
@dmlloyd one last commit, just to doco your findings as well, and warn users
doing "atypical" things, that they may be burned in future :smile:
> 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)
