[jira] [Commented] (MNG-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807623#comment-17807623
]
ASF GitHub Bot commented on MNG-8015:
-
gnodet commented on code in PR #1378:
URL: https://github.com/apache/maven/pull/1378#discussion_r1453039589
##
api/maven-api-core/src/main/java/org/apache/maven/api/DependencyProperties.java:
##
@@ -33,27 +36,226 @@
@Immutable
public interface DependencyProperties {
/**
- * Boolean flag telling that dependency contains all of its dependencies.
Value of this key should be parsed with
- * {@link Boolean#parseBoolean(String)} to obtain value.
+ * Keys in the dependency properties map.
+ * Each key can be associated to values of a specific class.
+ *
+ * @paramtype of value associated to the key
+ */
+class Key {
+/**
+ * The keys that are defined in this {@code DependencyProperties} map.
+ * Accesses to this map shall be synchronized on the map.
+ *
+ * @see #intern()
+ */
+private static final Map> INTERNS = new HashMap<>();
Review Comment:
Can we use a `ConcurrentHashMap` rather than a `HashMap` and synchronizing
access to it ?
##
api/maven-api-core/src/main/java/org/apache/maven/api/DependencyProperties.java:
##
@@ -33,27 +36,226 @@
@Immutable
public interface DependencyProperties {
/**
- * Boolean flag telling that dependency contains all of its dependencies.
Value of this key should be parsed with
- * {@link Boolean#parseBoolean(String)} to obtain value.
+ * Keys in the dependency properties map.
+ * Each key can be associated to values of a specific class.
+ *
+ * @paramtype of value associated to the key
+ */
+class Key {
+/**
+ * The keys that are defined in this {@code DependencyProperties} map.
+ * Accesses to this map shall be synchronized on the map.
+ *
+ * @see #intern()
+ */
+private static final Map> INTERNS = new HashMap<>();
+
+/**
+ * Value returned by {@link #name()}.
+ */
+@Nonnull
+private final String name;
+
+/**
+ * Value returned by {@link #valueType()}.
+ */
+@Nonnull
+private final Class valueType;
+
+/**
+ * Creates a new key.
+ *
+ * @param name name of the key
+ * @param valueType type of value associated to the key
+ */
+public Key(@Nonnull final String name, @Nonnull final Class
valueType) {
+this.name = Objects.requireNonNull(name);
+this.valueType = Objects.requireNonNull(valueType);
+}
+
+/**
+ * If a key exists in the {@linkplain #intern() intern pool} for the
given name, returns that key.
+ * Otherwise, if the {@code defaultType} is non-null, creates a key
for values of the specified type.
+ * Otherwise, returns {@code null}.
+ *
+ * @param name name of the key to search or create
+ * @param defaultType value type of the key to create if none exist
for the given name, or {@code null}
+ * @return key found or created, or {@code null} if no key was found
and {@code defaultType} is null
+ *
+ * @see #intern()
+ */
+public static Key forName(String name, Class defaultType) {
+Key key;
+synchronized (INTERNS) {
+key = INTERNS.get(name);
+}
+if (key == null && defaultType != null) {
+key = new Key<>(name, defaultType);
+}
+return key;
+}
+
+/**
+ * {@return the name of the key}.
+ */
+@Nonnull
+public String name() {
+return name;
+}
+
+/**
+ * {@return the type of value associated to the key}.
+ */
+@Nonnull
+public Class valueType() {
+return valueType;
+}
+
+/**
+ * {@return a canonical representation of this key}. A pool of keys,
initially empty, is maintained privately.
+ * When the {@code intern()} method is invoked, if the pool already
contains a key equal to this {@code Key}
+ * as determined by the {@link #equals(Object)} method, then the key
from the pool is returned. Otherwise,
+ * if no key exist in the pool for this key {@linkplain #name() name},
then this {@code Key} object is added
+ * to the pool and {@code this} is returned. Otherwise an {@link
IllegalStateException} is thrown.
+ *
+ * @throws IllegalStateException if a key exists in the pool for the
same name but a different class of values.
+ *
+ * @see String#intern()
+ */
+@SuppressWarnings("unchecked")
+public Key intern()
[jira] [Commented] (MNG-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807625#comment-17807625
]
ASF GitHub Bot commented on MNG-8015:
-
gnodet commented on code in PR #1378:
URL: https://github.com/apache/maven/pull/1378#discussion_r1453039589
##
api/maven-api-core/src/main/java/org/apache/maven/api/DependencyProperties.java:
##
@@ -33,27 +36,226 @@
@Immutable
public interface DependencyProperties {
/**
- * Boolean flag telling that dependency contains all of its dependencies.
Value of this key should be parsed with
- * {@link Boolean#parseBoolean(String)} to obtain value.
+ * Keys in the dependency properties map.
+ * Each key can be associated to values of a specific class.
+ *
+ * @paramtype of value associated to the key
+ */
+class Key {
+/**
+ * The keys that are defined in this {@code DependencyProperties} map.
+ * Accesses to this map shall be synchronized on the map.
+ *
+ * @see #intern()
+ */
+private static final Map> INTERNS = new HashMap<>();
Review Comment:
Can we use a `ConcurrentHashMap` rather than a `HashMap` and synchronizing
access to it ? But see below... is that needed at all ?
> Control the type of path where each dependency can be placed
>
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 4.0.0-alpha-12
>Reporter: Martin Desruisseaux
>Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{modular-jar}} implies {{PathType.MODULES}} only.
> * {{classpath-jar}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{jar}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8015] Control the type of path where each dependency can be placed [maven]
gnodet commented on code in PR #1378:
URL: https://github.com/apache/maven/pull/1378#discussion_r1453039589
##
api/maven-api-core/src/main/java/org/apache/maven/api/DependencyProperties.java:
##
@@ -33,27 +36,226 @@
@Immutable
public interface DependencyProperties {
/**
- * Boolean flag telling that dependency contains all of its dependencies.
Value of this key should be parsed with
- * {@link Boolean#parseBoolean(String)} to obtain value.
+ * Keys in the dependency properties map.
+ * Each key can be associated to values of a specific class.
+ *
+ * @paramtype of value associated to the key
+ */
+class Key {
+/**
+ * The keys that are defined in this {@code DependencyProperties} map.
+ * Accesses to this map shall be synchronized on the map.
+ *
+ * @see #intern()
+ */
+private static final Map> INTERNS = new HashMap<>();
Review Comment:
Can we use a `ConcurrentHashMap` rather than a `HashMap` and synchronizing
access to it ? But see below... is that needed at all ?
--
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] [MNG-8015] Control the type of path where each dependency can be placed [maven]
gnodet commented on code in PR #1378:
URL: https://github.com/apache/maven/pull/1378#discussion_r1453039589
##
api/maven-api-core/src/main/java/org/apache/maven/api/DependencyProperties.java:
##
@@ -33,27 +36,226 @@
@Immutable
public interface DependencyProperties {
/**
- * Boolean flag telling that dependency contains all of its dependencies.
Value of this key should be parsed with
- * {@link Boolean#parseBoolean(String)} to obtain value.
+ * Keys in the dependency properties map.
+ * Each key can be associated to values of a specific class.
+ *
+ * @paramtype of value associated to the key
+ */
+class Key {
+/**
+ * The keys that are defined in this {@code DependencyProperties} map.
+ * Accesses to this map shall be synchronized on the map.
+ *
+ * @see #intern()
+ */
+private static final Map> INTERNS = new HashMap<>();
Review Comment:
Can we use a `ConcurrentHashMap` rather than a `HashMap` and synchronizing
access to it ?
##
api/maven-api-core/src/main/java/org/apache/maven/api/DependencyProperties.java:
##
@@ -33,27 +36,226 @@
@Immutable
public interface DependencyProperties {
/**
- * Boolean flag telling that dependency contains all of its dependencies.
Value of this key should be parsed with
- * {@link Boolean#parseBoolean(String)} to obtain value.
+ * Keys in the dependency properties map.
+ * Each key can be associated to values of a specific class.
+ *
+ * @paramtype of value associated to the key
+ */
+class Key {
+/**
+ * The keys that are defined in this {@code DependencyProperties} map.
+ * Accesses to this map shall be synchronized on the map.
+ *
+ * @see #intern()
+ */
+private static final Map> INTERNS = new HashMap<>();
+
+/**
+ * Value returned by {@link #name()}.
+ */
+@Nonnull
+private final String name;
+
+/**
+ * Value returned by {@link #valueType()}.
+ */
+@Nonnull
+private final Class valueType;
+
+/**
+ * Creates a new key.
+ *
+ * @param name name of the key
+ * @param valueType type of value associated to the key
+ */
+public Key(@Nonnull final String name, @Nonnull final Class
valueType) {
+this.name = Objects.requireNonNull(name);
+this.valueType = Objects.requireNonNull(valueType);
+}
+
+/**
+ * If a key exists in the {@linkplain #intern() intern pool} for the
given name, returns that key.
+ * Otherwise, if the {@code defaultType} is non-null, creates a key
for values of the specified type.
+ * Otherwise, returns {@code null}.
+ *
+ * @param name name of the key to search or create
+ * @param defaultType value type of the key to create if none exist
for the given name, or {@code null}
+ * @return key found or created, or {@code null} if no key was found
and {@code defaultType} is null
+ *
+ * @see #intern()
+ */
+public static Key forName(String name, Class defaultType) {
+Key key;
+synchronized (INTERNS) {
+key = INTERNS.get(name);
+}
+if (key == null && defaultType != null) {
+key = new Key<>(name, defaultType);
+}
+return key;
+}
+
+/**
+ * {@return the name of the key}.
+ */
+@Nonnull
+public String name() {
+return name;
+}
+
+/**
+ * {@return the type of value associated to the key}.
+ */
+@Nonnull
+public Class valueType() {
+return valueType;
+}
+
+/**
+ * {@return a canonical representation of this key}. A pool of keys,
initially empty, is maintained privately.
+ * When the {@code intern()} method is invoked, if the pool already
contains a key equal to this {@code Key}
+ * as determined by the {@link #equals(Object)} method, then the key
from the pool is returned. Otherwise,
+ * if no key exist in the pool for this key {@linkplain #name() name},
then this {@code Key} object is added
+ * to the pool and {@code this} is returned. Otherwise an {@link
IllegalStateException} is thrown.
+ *
+ * @throws IllegalStateException if a key exists in the pool for the
same name but a different class of values.
+ *
+ * @see String#intern()
+ */
+@SuppressWarnings("unchecked")
+public Key intern() {
+Key previous;
+synchronized (INTERNS) {
+previous = INTERNS.putIfAbsent(name, this);
+}
+if (previous == null) {
+return this;
+}
+if (equals(
[jira] [Updated] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[ https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-1351: --- Fix Version/s: maven-filtering-3.3.2 > Confusing message when copying resources from project's baseDir > --- > > Key: MSHARED-1351 > URL: https://issues.apache.org/jira/browse/MSHARED-1351 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.3.1 >Reporter: Abel Salgado Romero >Priority: Minor > Fix For: maven-filtering-3.3.2 > > > When the project base dir is used as the origin path, the relativize in > https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 > resolves to empty string, resulting in nothing being displayed path after > "from" in the console: > ``` > Copying 118 resources from to target/generated-docs > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[ https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807597#comment-17807597 ] ASF GitHub Bot commented on MSHARED-1351: - hboutemy commented on code in PR #93: URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1454778432 ## src/test/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFilteringTest.java: ## @@ -24,13 +24,10 @@ import java.io.FileInputStream; import java.io.IOException; import java.nio.file.Files; -import java.util.ArrayList; -import java.util.Arrays; -import java.util.Collections; -import java.util.List; -import java.util.Properties; +import java.util.*; Review Comment: please don't reformat this > Confusing message when copying resources from project's baseDir > --- > > Key: MSHARED-1351 > URL: https://issues.apache.org/jira/browse/MSHARED-1351 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.3.1 >Reporter: Abel Salgado Romero >Priority: Minor > > When the project base dir is used as the origin path, the relativize in > https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 > resolves to empty string, resulting in nothing being displayed path after > "from" in the console: > ``` > Copying 118 resources from to target/generated-docs > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93: URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1454778432 ## src/test/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFilteringTest.java: ## @@ -24,13 +24,10 @@ import java.io.FileInputStream; import java.io.IOException; import java.nio.file.Files; -import java.util.ArrayList; -import java.util.Arrays; -import java.util.Collections; -import java.util.List; -import java.util.Properties; +import java.util.*; Review Comment: please don't reformat this -- 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] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1454775248
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
yes, `.` instead of `base directory`
--
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] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807595#comment-17807595
]
ASF GitHub Bot commented on MSHARED-1351:
-
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1454775248
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
yes, `.` technically valid value instead of `base directory` human
readable-only
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1454775248
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
yes, `.` technically valid value instead of `base directory` human
readable-only
--
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] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807594#comment-17807594
]
ASF GitHub Bot commented on MSHARED-1351:
-
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1454775248
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
yes, `.` instead of `base directory`
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-327) Support multi-language for menu "name"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807588#comment-17807588 ] Michael Osipov commented on DOXIASITETOOLS-327: --- Wait, we do have multilingual sites with locales. Look at Site Plugin ITs. > Support multi-language for menu "name" > -- > > Key: DOXIASITETOOLS-327 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-327 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site model >Affects Versions: 2.0.0-M16 >Reporter: Abel Salgado Romero >Priority: Minor > Attachments: image-2024-01-16-23-19-41-511.png > > > The new v2.0.x-MX added multi-lang / locale support to build pages, but seems > the `site.xml` does not allow to change the name of a menu element. > For example, a page with "en" and "es" versions and menu "Hello", will show > "Hello" in the Spanish site too, no way to specify "Hola". > > I peeked at the code and I see two options: > # Modify MenuItem to allow a sub name element like ` locale="es">Hola` > # Allow injection of language ResourceBundle properties in the current > element: `` > I like the second and will try to explore that, I saw the generated code > provides a transformer method for values, just need to find how to inject > custom logic there 🤔 > !image-2024-01-16-23-19-41-511.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump org.cyclonedx:cyclonedx-maven-plugin from 2.7.10 to 2.7.11 [maven-parent]
dependabot[bot] opened a new pull request, #159: URL: https://github.com/apache/maven-parent/pull/159 Bumps [org.cyclonedx:cyclonedx-maven-plugin](https://github.com/CycloneDX/cyclonedx-maven-plugin) from 2.7.10 to 2.7.11. Release notes Sourced from https://github.com/CycloneDX/cyclonedx-maven-plugin/releases";>org.cyclonedx:cyclonedx-maven-plugin's releases. 2.7.11 🚀 New features and improvements rename convert methohds to explicit project vs dependency (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/456";>#456) https://github.com/hboutemy";>@hboutemy cleanup unused code (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/455";>#455) https://github.com/hboutemy";>@hboutemy test dependency type=zip for https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/issues/431";>#431 (reverts https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/issues/9";>#9) (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/454";>#454) https://github.com/hboutemy";>@hboutemy Support metadata when dependency is any other dependency type than jar (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/431";>#431) https://github.com/AlbGarciam";>@AlbGarciam Add support for custom external references (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/428";>#428) https://github.com/vy";>@vy Add a configuration option to skip undeployed artifacts (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/435";>#435) https://github.com/ppkarwasz";>@ppkarwasz use metadata properties in UUID (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/441";>#441) https://github.com/hboutemy";>@hboutemy Generate serial numbers deterministically (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/issues/420";>#420) (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/425";>#425) https://github.com/vy";>@vy 📦 Dependency updates define plugin-tools.version property (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/453";>#453) https://github.com/hboutemy";>@hboutemy Bump org.apache.maven.plugin-tools:maven-plugin-annotations from 3.10.2 to 3.11.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/451";>#451) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-plugin-report-plugin from 3.10.2 to 3.11.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/450";>#450) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-plugin-plugin from 3.10.2 to 3.11.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/449";>#449) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-compiler-plugin from 3.11.0 to 3.12.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/447";>#447) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-plugin-plugin from 3.10.1 to 3.10.2 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/445";>#445) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-project-info-reports-plugin from 3.4.5 to 3.5.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/442";>#442) https://github.com/dependabot";>@dependabot Bump org.apache.commons:commons-lang3 from 3.13.0 to 3.14.0 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/443";>#443) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugin-tools:maven-plugin-annotations from 3.10.1 to 3.10.2 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/444";>#444) https://github.com/dependabot";>@dependabot Bump org.junit:junit-bom from 5.10.0 to 5.10.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/422";>#422) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-plugin-report-plugin from 3.10.1 to 3.10.2 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/424";>#424) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-javadoc-plugin from 3.6.0 to 3.6.3 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/438";>#438) https://github.com/dependabot";>@dependabot Bump actions/setup-java from 3 to 4 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/437";>#437) https://github.com/dependabot";>@dependabot Bump org.apache.maven.plugins:maven-plugin-report-plugin from 3.9.0 to 3.10.1 (https://redirect.github.com/CycloneDX/cyclonedx-maven-plugin/pull/417";>#417) https://github.com/dependabot";>@dependabot Commits https://github.com/CycloneDX/cyclonedx-maven-plugin/commit/349fe7cc7fd8b7f2224075b5fe7d73e7f0832140";>349fe7c [maven-release-plugin] prepare release cyclonedx-maven-plug
Re: [PR] Bump org.apache.maven.resolver:maven-resolver-transport-http from 1.9.7 to 1.9.18 [maven-build-cache-extension]
dependabot[bot] merged PR #123: URL: https://github.com/apache/maven-build-cache-extension/pull/123 -- 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 org.assertj:assertj-core from 3.24.2 to 3.25.1 [maven-build-cache-extension]
dependabot[bot] merged PR #125: URL: https://github.com/apache/maven-build-cache-extension/pull/125 -- 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] (DOXIASITETOOLS-327) Support multi-language for menu "name"
Abel Salgado Romero created DOXIASITETOOLS-327: -- Summary: Support multi-language for menu "name" Key: DOXIASITETOOLS-327 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-327 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site model Affects Versions: 2.0.0-M16 Reporter: Abel Salgado Romero Attachments: image-2024-01-16-23-19-41-511.png The new v2.0.x-MX added multi-lang / locale support to build pages, but seems the `site.xml` does not allow to change the name of a menu element. For example, a page with "en" and "es" versions and menu "Hello", will show "Hello" in the Spanish site too, no way to specify "Hola". I peeked at the code and I see two options: # Modify MenuItem to allow a sub name element like `Hola` # Allow injection of language ResourceBundle properties in the current element: `` I like the second and will try to explore that, I saw the generated code provides a transformer method for values, just need to find how to inject custom logic there 🤔 !image-2024-01-16-23-19-41-511.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSITE-1000) Allow parametrisation of Doxia parser per file
[
https://issues.apache.org/jira/browse/MSITE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807467#comment-17807467
]
Abel Salgado Romero edited comment on MSITE-1000 at 1/16/24 10:08 PM:
--
If I understand, this story is to allow clean configuration of other modules.
If it helps, you can have a look at how we hacked our way around the
limitations. It's similar to the proposal. This improvement is very appreciated
and I look forward to seeing this completed.
Here is how we do it, we added a custom element `` to the
configuration, which we simply parsed by hand accessing the POM's XML
(obviously IDE complain, but it works):
* Get Xpp3Dom
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L106-L108]
* Parse XML by hand to generate converted API object
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/SiteConversionConfigurationParser.java#L46-L80]
* Pass the specific API object to the converter
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L79]
The parser configuration is varied, strings (some could be enums), booleans,
and free key-value maps.
My only issue with the example is `parserConfigurations`, there should be a way
to identify the config owner, you could have AsciiDoc and MarkDown and each one
requires different configuation. I like having the tag be called ``
{{}}
{{ }}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{ }}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{}}
Instead of something with a tag like:
{{}}
{{ }}
{{ asciidoc}}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{ }}
{{ markdownc}}
{{ }}
{{ *{*}/apt/{*}*}}
{{ }}
{{ }}
{{}}
was (Author: abel s.romero):
If I understand, this story is to allow clean configuration of other modules.
If it helps, you can have a look at how we hacked our way around the
limitations. It's similar to the proposal. This improvement is very appreciated
and I look forward to seeing this completed.
Here is how we do it, we added a custom element `` to the
configuration, which we simply parsed by hand accessing the POM's XML
(obviously IDE complain, but it works):
* Get Xpp3Dom
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L106-L108]
* Parse XML by hand to generate converted API object
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/SiteConversionConfigurationParser.java#L46-L80]
* Pass the specific API object to the converter
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L79]
The parser configuration is varied, strings (some could be enums), booleans,
and free key-value maps.
My only issue with the example is `parserConfigurations`, there should be a way
to identify the config owner, you could have AsciiDoc and MarkDown and each one
requires different configuation. I like having the tag be called ``
**/apt/**
**/apt/**
Instead of something with a tag like:
asciidoc
**/apt/**
markdownc
**/apt/**
> Allow parametrisation of Doxia parser per file
> --
>
> Key: MSITE-1000
> URL: https://issues.apache.org/jira/browse/MSITE-1000
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently only the attributes used for rendering the site can be
> parameterized in
> https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
> There is no possibility to configure the parser in
> https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
> per document.
> This would be nice in the context of
> https://issues.apache.org/jira/browse/DOXIA-722 where generation of anchors
> should be switched on/off for certain documents. Also generation of comments
> may be desirable for certain documents.
> I propose the following additional plugin goal parameter:
> {code}
>
>
>
> **/apt/**
>
>
[jira] [Commented] (MSITE-1000) Allow parametrisation of Doxia parser per file
[
https://issues.apache.org/jira/browse/MSITE-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807467#comment-17807467
]
Abel Salgado Romero commented on MSITE-1000:
If I understand, this story is to allow clean configuration of other modules.
If it helps, you can have a look at how we hacked our way around the
limitations. It's similar to the proposal. This improvement is very appreciated
and I look forward to seeing this completed.
Here is how we do it, we added a custom element `` to the
configuration, which we simply parsed by hand accessing the POM's XML
(obviously IDE complain, but it works):
* Get Xpp3Dom
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L106-L108]
* Parse XML by hand to generate converted API object
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/SiteConversionConfigurationParser.java#L46-L80]
* Pass the specific API object to the converter
[https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/80c699035933aae133afaf9592bcc065c3d41b74/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L79]
The parser configuration is varied, strings (some could be enums), booleans,
and free key-value maps.
My only issue with the example is `parserConfigurations`, there should be a way
to identify the config owner, you could have AsciiDoc and MarkDown and each one
requires different configuation. I like having the tag be called ``
**/apt/**
**/apt/**
Instead of something with a tag like:
asciidoc
**/apt/**
markdownc
**/apt/**
> Allow parametrisation of Doxia parser per file
> --
>
> Key: MSITE-1000
> URL: https://issues.apache.org/jira/browse/MSITE-1000
> Project: Maven Site Plugin
> Issue Type: New Feature
> Components: doxia integration
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently only the attributes used for rendering the site can be
> parameterized in
> https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#attributes.
> There is no possibility to configure the parser in
> https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L322
> per document.
> This would be nice in the context of
> https://issues.apache.org/jira/browse/DOXIA-722 where generation of anchors
> should be switched on/off for certain documents. Also generation of comments
> may be desirable for certain documents.
> I propose the following additional plugin goal parameter:
> {code}
>
>
>
> **/apt/**
>
> false
> true
>
>
> {code}
> where {{parserConfigurations}} is an array of a complex type with (include)
> patterns on the source path (String array) and boolean methods for features.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[
https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807421#comment-17807421
]
Tamas Cservenak edited comment on MNG-7539 at 1/16/24 7:49 PM:
---
[~adrian.tarau] am unsure about 3.8.x, but in 3.9.x the resolutions ARE cached
within a session (in case of mvn, within one CLI invocation) UNLESS configured
to not do that, while default is do cache. Best would be to see a reproducer
project, as until then, I consider this issue as "cannot reproduce".
Do you may use some extension (or IDE) that provides some custom
{{WorkspaceReader}} maybe?
was (Author: cstamas):
[~adrian.tarau] am unsure about 3.8.x, but in 3.9.x the resolutions ARE cached
within a session (in case of mvn, within one CLI invocation) UNLESS configured
to not do that, while default is do cache. Best would be to see a reproducer
project, as until then, I consider this issue as "cannot reproduce".
> Validate/Download SNAPSHOT dependencies once
>
>
> Key: MNG-7539
> URL: https://issues.apache.org/jira/browse/MNG-7539
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Adrian Tarau
>Priority: Major
>
> Building an unreleased multi-module project (30-40 modules) that depends on
> various other unreleased modules puts significant pressure on the Maven
> Repository (a local Nexus instance), and artifact resolution could slow down
> the build 2x-3x.
> I do acknowledge that it is the job of the repository to cache and serve
> those responses fast, and for some reason, sometimes it slows down without an
> apparent reason.
> However, the whole build process will be faster if Maven validates a SNAPSHOT
> once for multi-module (when the dependency is reached the first time) and
> then use that version. Even if Maven Repository is relative fast, there is
> still network traffic done. Outside the fact that it should not be done, it
> might also introduce flaky behaviors:
> * one module downloads a version of artifact A, works with it, and
> everything is fine
> * 10 minutes later, another module needs artifact A and gets a newer
> version, which has some issues, and various (test) failures will be raised
> For consistency, on a multi-module build, all modules should _see_ the same
> version of a SNAPSHOT artifact. It will be faster, and it will be consistent
> (which is very important).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[ https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807421#comment-17807421 ] Tamas Cservenak commented on MNG-7539: -- [~adrian.tarau] am unsure about 3.8.x, but in 3.9.x the resolutions ARE cached within a session (in case of mvn, within one CLI invocation) UNLESS configured to not do, while default is do cache. Best would be to see a reproducer project, as until then, I consider this issue as "cannot reproduce". > Validate/Download SNAPSHOT dependencies once > > > Key: MNG-7539 > URL: https://issues.apache.org/jira/browse/MNG-7539 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Adrian Tarau >Priority: Major > > Building an unreleased multi-module project (30-40 modules) that depends on > various other unreleased modules puts significant pressure on the Maven > Repository (a local Nexus instance), and artifact resolution could slow down > the build 2x-3x. > I do acknowledge that it is the job of the repository to cache and serve > those responses fast, and for some reason, sometimes it slows down without an > apparent reason. > However, the whole build process will be faster if Maven validates a SNAPSHOT > once for multi-module (when the dependency is reached the first time) and > then use that version. Even if Maven Repository is relative fast, there is > still network traffic done. Outside the fact that it should not be done, it > might also introduce flaky behaviors: > * one module downloads a version of artifact A, works with it, and > everything is fine > * 10 minutes later, another module needs artifact A and gets a newer > version, which has some issues, and various (test) failures will be raised > For consistency, on a multi-module build, all modules should _see_ the same > version of a SNAPSHOT artifact. It will be faster, and it will be consistent > (which is very important). > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[ https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807421#comment-17807421 ] Tamas Cservenak edited comment on MNG-7539 at 1/16/24 7:48 PM: --- [~adrian.tarau] am unsure about 3.8.x, but in 3.9.x the resolutions ARE cached within a session (in case of mvn, within one CLI invocation) UNLESS configured to not do that, while default is do cache. Best would be to see a reproducer project, as until then, I consider this issue as "cannot reproduce". was (Author: cstamas): [~adrian.tarau] am unsure about 3.8.x, but in 3.9.x the resolutions ARE cached within a session (in case of mvn, within one CLI invocation) UNLESS configured to not do, while default is do cache. Best would be to see a reproducer project, as until then, I consider this issue as "cannot reproduce". > Validate/Download SNAPSHOT dependencies once > > > Key: MNG-7539 > URL: https://issues.apache.org/jira/browse/MNG-7539 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Adrian Tarau >Priority: Major > > Building an unreleased multi-module project (30-40 modules) that depends on > various other unreleased modules puts significant pressure on the Maven > Repository (a local Nexus instance), and artifact resolution could slow down > the build 2x-3x. > I do acknowledge that it is the job of the repository to cache and serve > those responses fast, and for some reason, sometimes it slows down without an > apparent reason. > However, the whole build process will be faster if Maven validates a SNAPSHOT > once for multi-module (when the dependency is reached the first time) and > then use that version. Even if Maven Repository is relative fast, there is > still network traffic done. Outside the fact that it should not be done, it > might also introduce flaky behaviors: > * one module downloads a version of artifact A, works with it, and > everything is fine > * 10 minutes later, another module needs artifact A and gets a newer > version, which has some issues, and various (test) failures will be raised > For consistency, on a multi-module build, all modules should _see_ the same > version of a SNAPSHOT artifact. It will be faster, and it will be consistent > (which is very important). > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DOXIA-726) MarkdownSink: Incorrect escaping of <
[
https://issues.apache.org/jira/browse/DOXIA-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-726:
--
Component/s: Module - Markdown
> MarkdownSink: Incorrect escaping of <,>,",' and &
> -
>
> Key: DOXIA-726
> URL: https://issues.apache.org/jira/browse/DOXIA-726
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As Markdown emits all unknown characters "as-is" in the resulting HTML also
> all XML escape characters need to be leveraged in addition to the ones
> outlined in https://daringfireball.net/projects/markdown/syntax#backslash in
> {{Sink.text(...)}}. Currently only the latter is considered though which
> leads to incorrect output: The text value
> {code}
> "this is a "
> {code}
> should lead to
> {code}
> "this is a "
> {code}
> but right now the "<" and ">" are not escaped.
> Compare also with
> https://spec.commonmark.org/0.30/#entity-and-numeric-character-references.
> It needs to be ensured that all parsed XHTML elements which are not natively
> supported by the Sink API (i.e. don't lead to a dedicated event) are passed
> as is to the output (given the input is XHTML).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-727) MarkdownSink: Incorrect escaping inside code spans
Konrad Windszus created DOXIA-727:
-
Summary: MarkdownSink: Incorrect escaping inside code spans
Key: DOXIA-727
URL: https://issues.apache.org/jira/browse/DOXIA-727
Project: Maven Doxia
Issue Type: Bug
Components: Module - Markdown
Reporter: Konrad Windszus
Assignee: Konrad Windszus
According to https://spec.commonmark.org/0.30/#backslash-escapes
bq. Backslash escapes do not work in code blocks, code spans, autolinks, or raw
HTML
Currently the escaping is not disabled between {{Sink.inline(...)}} and
{{Sink.inline(...)}} with "code" semantics (also used from
{{Sink.monospaced()}}) (emits a code span) but only in between
{{Sink.verbatim()}} and {{Sink.verbatim()_}} (emits a code block).
autolinks and raw HTML are currently either never emitted or don't use escaping
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-726) MarkdownSink: Incorrect escaping of <
[
https://issues.apache.org/jira/browse/DOXIA-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807409#comment-17807409
]
ASF GitHub Bot commented on DOXIA-726:
--
kwin opened a new pull request, #196:
URL: https://github.com/apache/maven-doxia/pull/196
Use XML entities prior to escaping for Markdown with a backslash
> MarkdownSink: Incorrect escaping of <,>,",' and &
> -
>
> Key: DOXIA-726
> URL: https://issues.apache.org/jira/browse/DOXIA-726
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As Markdown emits all unknown characters "as-is" in the resulting HTML also
> all XML escape characters need to be leveraged in addition to the ones
> outlined in https://daringfireball.net/projects/markdown/syntax#backslash in
> {{Sink.text(...)}}. Currently only the latter is considered though which
> leads to incorrect output: The text value
> {code}
> "this is a "
> {code}
> should lead to
> {code}
> "this is a "
> {code}
> but right now the "<" and ">" are not escaped.
> Compare also with
> https://spec.commonmark.org/0.30/#entity-and-numeric-character-references.
> It needs to be ensured that all parsed XHTML elements which are not natively
> supported by the Sink API (i.e. don't lead to a dedicated event) are passed
> as is to the output (given the input is XHTML).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [DOXIA-726] Incorrect escaping of <,>,",' and & [maven-doxia]
kwin opened a new pull request, #196: URL: https://github.com/apache/maven-doxia/pull/196 Use XML entities prior to escaping for Markdown with a backslash -- 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] (DOXIA-726) MarkdownSink: Incorrect escaping of <
[
https://issues.apache.org/jira/browse/DOXIA-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-726:
--
Description:
As Markdown emits all unknown characters "as-is" in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped.
Compare also with
https://spec.commonmark.org/0.30/#entity-and-numeric-character-references.
It needs to be ensured that all parsed XHTML elements which are not natively
supported by the Sink API (i.e. don't lead to a dedicated event) are passed as
is to the output (given the input is XHTML).
was:
As Markdown emits all unknown characters "as-is" in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped.
It needs to be ensured that all parsed XHTML elements which are not natively
supported by the Sink API (i.e. don't lead to a dedicated event) are passed as
is to the output (given the input is XHTML).
> MarkdownSink: Incorrect escaping of <,>,",' and &
> -
>
> Key: DOXIA-726
> URL: https://issues.apache.org/jira/browse/DOXIA-726
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As Markdown emits all unknown characters "as-is" in the resulting HTML also
> all XML escape characters need to be leveraged in addition to the ones
> outlined in https://daringfireball.net/projects/markdown/syntax#backslash in
> {{Sink.text(...)}}. Currently only the latter is considered though which
> leads to incorrect output: The text value
> {code}
> "this is a "
> {code}
> should lead to
> {code}
> "this is a "
> {code}
> but right now the "<" and ">" are not escaped.
> Compare also with
> https://spec.commonmark.org/0.30/#entity-and-numeric-character-references.
> It needs to be ensured that all parsed XHTML elements which are not natively
> supported by the Sink API (i.e. don't lead to a dedicated event) are passed
> as is to the output (given the input is XHTML).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807406#comment-17807406
]
ASF GitHub Bot commented on MRESOLVER-264:
--
cstamas commented on PR #405:
URL: https://github.com/apache/maven-resolver/pull/405#issuecomment-1894318487
That above is true only if check out commit BEFORE
860973e63eed8436ab450e5aa04e1a16c9e83870 of course, now that master is up to
date, doco will have no change generated.
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPMD-386) Resolution of suppression file failes using the "-f" parameter since 3.15.0
[
https://issues.apache.org/jira/browse/MPMD-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Bünger updated MPMD-386:
-
Summary: Resolution of suppression file failes using the "-f" parameter
since 3.15.0 (was: Resolution of suppression file failes using the "-f"
parameter since 3.1.5.0)
> Resolution of suppression file failes using the "-f" parameter since 3.15.0
> ---
>
> Key: MPMD-386
> URL: https://issues.apache.org/jira/browse/MPMD-386
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.15.0, 3.16.0, 3.17.0, 3.18.0, 3.19.0, 3.20.0, 3.21.0
>Reporter: Matthias Bünger
>Priority: Major
> Attachments: meta-pom.xml
>
>
> I finally upgraded the maven-pmd-update of our meta POM, because I always
> forgot to upgrade this particular one too. I tried to upgrade from 3.12.0 to
> 3.21.0, but realized that our local and CI builds break after upgrading,
> becuase our exclude files are not found anymore, when using the "{{{}-f{}}}"
> parameter.
> I could nail it down that the break comes with 3.15.0, but I can not explain
> why. The only ticket I could imagine to has something to do with it is
> MPMD-323, but this is of 3.16.0, so I might be wrong at all.
> Background and setup:
> We have tons of Maven projects within own repositories, each with one of the
> four structure:
> a) Single or multi-module project
> b) Root-pom in root directory or in a folder below
> The pmd-excludes file lies in same folder as the root-pom. So we have the
> following setups
> Single-module
> {code}
> /
> ├─ src/
> │ ├─ ...
> ├─ pom.xml
> ├─ exclude-pmd.properties
>
> /
> ├─ componentDir
> ├─ src/
> │ ├─ ...
> ├─ pom.xml
> ├─ exclude-pmd.properties
> {code}
> Same for multi module
> {code}
> /
> ├─ moduleA
> │ ├─src/
> │ │ ├─ ...
> ├─ moduleb
> │ ├─src/
> │ │ ├─ ...
> ├─ pom.xml
> ├─ exclude-pmd.properties
> /
> ├─ componentDir
> ├─ moduleA
> │ ├─src/
> │ │ ├─ ...
> ├─ moduleb
> │ ├─src/
> │ │ ├─ ...
> ├─ pom.xml
> ├─ exclude-pmd.properties
> {code}
> As we have so many Maven projects we don't create individual Jenkins
> pipelines for each of them due the massive amount of work needed to maintain
> them. The call this in one of the two ways, depending on the the pipeline
> (verify or site), both using the "{{{}-f{}}}" parameter. On local developer
> machines we just start the build in die root pom directory without the
> "{{{}-f{}}}" parameter.
> While the resolution of the suppression file of the maven checkstyle plugin
> works like a charm by only using this
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
>
> checkstyle-suppressions.xml
>
>
>
>
> {code}
> The resolution of the suppression file of the pmd plugin worked somehow
> different, so we used the following universal approach to make it work for
> all our projects
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-pmd-plugin
>
>
> ${path.to.suppressfile.wo.slash}/exclude-pmd.properties
>
>
>
>
> {code}
> where "path.to.suppressfile.wo.slash" is
> {code:xml}
> multi-module
>
> ${project.basedir}/..
> single-module
> ${project.basedir}
> {code}
> This worked until 3.14.0, but failed after I upgraded to 3.15.0 in local and
> Jenkins builds.
> I could make the local build work again by changing the configuration to the
> same as the checkstyle plugin
> {code:xml}
> exclude-pmd.properties
> {code}
> When I looked at the changes made in MPMD-323, it seems to only affect the
> ruleset file, but it seems to also affects the suppression file, as the maven
> build fails when using the "{{{}-f{}}}" parameter.
> As this is my first time I get closer in contact with the PMD plugin sources
> I can't provide any more information right but, except the fact that the
> checkstyle plugin never had these kind of issues starting to use it in 2016
> up to current version 3.3.0.
> Full example meta-pom attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-264] Make file locking the default [maven-resolver]
cstamas commented on PR #405: URL: https://github.com/apache/maven-resolver/pull/405#issuecomment-1894318487 That above is true only if check out commit BEFORE 860973e63eed8436ab450e5aa04e1a16c9e83870 of course, now that master is up to date, doco will have no change generated. -- 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-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807404#comment-17807404
]
ASF GitHub Bot commented on MRESOLVER-264:
--
cstamas commented on PR #405:
URL: https://github.com/apache/maven-resolver/pull/405#issuecomment-1894317189
Right, forgot about it.
Luckily, is now generated, so if you check out master build, you'd end up
with "dirty" checkout, committed as 860973e63eed8436ab450e5aa04e1a16c9e83870
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-264] Make file locking the default [maven-resolver]
cstamas commented on PR #405: URL: https://github.com/apache/maven-resolver/pull/405#issuecomment-1894317189 Right, forgot about it. Luckily, is now generated, so if you check out master build, you'd end up with "dirty" checkout, committed as 860973e63eed8436ab450e5aa04e1a16c9e83870 -- 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] (DOXIA-726) MarkdownSink: Incorrect escaping of <
[
https://issues.apache.org/jira/browse/DOXIA-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-726:
--
Description:
As Markdown emits all unknown characters "as-is" in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped.
It needs to be ensured that all parsed XHTML elements which are not natively
supported by the Sink API (i.e. don't lead to a dedicated event) are passed as
is to the output (given the input is XHTML).
was:
As Markdown emits all unknown characters as is in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped.
It needs to be ensured that all parsed XHTML elements which are not natively
supported by the Sink API (i.e. don't lead to a dedicated event) are passed as
is to the output (given the input is XHTML).
> MarkdownSink: Incorrect escaping of <,>,",' and &
> -
>
> Key: DOXIA-726
> URL: https://issues.apache.org/jira/browse/DOXIA-726
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As Markdown emits all unknown characters "as-is" in the resulting HTML also
> all XML escape characters need to be leveraged in addition to the ones
> outlined in https://daringfireball.net/projects/markdown/syntax#backslash in
> {{Sink.text(...)}}. Currently only the latter is considered though which
> leads to incorrect output: The text value
> {code}
> "this is a "
> {code}
> should lead to
> {code}
> "this is a "
> {code}
> but right now the "<" and ">" are not escaped.
> It needs to be ensured that all parsed XHTML elements which are not natively
> supported by the Sink API (i.e. don't lead to a dedicated event) are passed
> as is to the output (given the input is XHTML).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIA-726) MarkdownSink: Incorrect escaping of <
[
https://issues.apache.org/jira/browse/DOXIA-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated DOXIA-726:
--
Description:
As Markdown emits all unknown characters as is in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped.
It needs to be ensured that all parsed XHTML elements which are not natively
supported by the Sink API (i.e. don't lead to a dedicated event) are passed as
is to the output (given the input is XHTML).
was:
As Markdown emits all unknown characters as is in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped
> MarkdownSink: Incorrect escaping of <,>,",' and &
> -
>
> Key: DOXIA-726
> URL: https://issues.apache.org/jira/browse/DOXIA-726
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As Markdown emits all unknown characters as is in the resulting HTML also all
> XML escape characters need to be leveraged in addition to the ones outlined
> in https://daringfireball.net/projects/markdown/syntax#backslash in
> {{Sink.text(...)}}. Currently only the latter is considered though which
> leads to incorrect output: The text value
> {code}
> "this is a "
> {code}
> should lead to
> {code}
> "this is a "
> {code}
> but right now the "<" and ">" are not escaped.
> It needs to be ensured that all parsed XHTML elements which are not natively
> supported by the Sink API (i.e. don't lead to a dedicated event) are passed
> as is to the output (given the input is XHTML).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DOXIA-726) MarkdownSink: Incorrect escaping of <
Konrad Windszus created DOXIA-726:
-
Summary: MarkdownSink: Incorrect escaping of <,>,",' and &
Key: DOXIA-726
URL: https://issues.apache.org/jira/browse/DOXIA-726
Project: Maven Doxia
Issue Type: Bug
Affects Versions: 2.0.0-M9
Reporter: Konrad Windszus
Assignee: Konrad Windszus
As Markdown emits all unknown characters as is in the resulting HTML also all
XML escape characters need to be leveraged in addition to the ones outlined in
https://daringfireball.net/projects/markdown/syntax#backslash in
{{Sink.text(...)}}. Currently only the latter is considered though which leads
to incorrect output: The text value
{code}
"this is a "
{code}
should lead to
{code}
"this is a "
{code}
but right now the "<" and ">" are not escaped
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807376#comment-17807376
]
ASF GitHub Bot commented on MRESOLVER-264:
--
michael-o commented on PR #405:
URL: https://github.com/apache/maven-resolver/pull/405#issuecomment-1894249873
What about docs?
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-264] Make file locking the default [maven-resolver]
michael-o commented on PR #405: URL: https://github.com/apache/maven-resolver/pull/405#issuecomment-1894249873 What about docs? -- 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] [Closed] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-264.
-
Resolution: Fixed
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807370#comment-17807370
]
ASF GitHub Bot commented on MRESOLVER-264:
--
cstamas merged PR #405:
URL: https://github.com/apache/maven-resolver/pull/405
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-264] Make file locking the default [maven-resolver]
cstamas merged PR #405: URL: https://github.com/apache/maven-resolver/pull/405 -- 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] [Closed] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-334.
-
Resolution: Fixed
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807369#comment-17807369
]
ASF GitHub Bot commented on MRESOLVER-334:
--
cstamas merged PR #486:
URL: https://github.com/apache/maven-site/pull/486
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807368#comment-17807368
]
Tamas Cservenak commented on MRESOLVER-334:
---
The fix of this issue is not happening in Resolver codebase, but on Maven Site
instead: https://github.com/apache/maven-site/pull/486
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-334] Align spec with implementation [maven-site]
cstamas merged PR #486: URL: https://github.com/apache/maven-site/pull/486 -- 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] Update pom.apt.vm [maven-site]
cstamas commented on code in PR #445:
URL: https://github.com/apache/maven-site/pull/445#discussion_r1453761767
##
content/apt/pom.apt.vm:
##
@@ -2033,4 +2033,4 @@ mvn help:active-profiles
==
Aspects of this guide were originally published in the
- {{{http://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html}Maven 2
Pom Demystified}}.
+
{{{https://web.archive.org/web/20100327140148/https://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html}Maven
2 Pom Demystified}}.
Review Comment:
@elharo I'm with your solution, no need a link to archive to Maven2...
--
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] Clarify default values for repositories [maven-site]
cstamas commented on PR #485: URL: https://github.com/apache/maven-site/pull/485#issuecomment-1894208603 LGTM Maybe, but just maybe add a sentence explaining this https://issues.apache.org/jira/browse/MRESOLVER-277 more specifically this comment https://issues.apache.org/jira/browse/MRESOLVER-277?focusedCommentId=17614487&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17614487 Here user had _empty_ repo and expected policy to kick in, that is applied only to cached 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] [Updated] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-334:
--
Fix Version/s: 2.0.0-alpha-7
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
[
https://issues.apache.org/jira/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17807362#comment-17807362
]
Matt Nelson commented on MCOMPILER-97:
--
{quote}
one could list the annotation processors or processor path explicitly, but this
results in a POM that is hard to develop and maintain (in the sense that one
would have to construct this enumeration and keep it up-to-date) in contrast
with a POM that does not list them explicitly and instead relies on the default
discovery behavior
{quote}
It appears that this is the direction that javac is heading towards.
https://inside.java/2023/10/23/quality-heads-up/
> META-INF/services/javax.annotation.processing.Processor copied before
> compilation and causes error
> --
>
> Key: MCOMPILER-97
> URL: https://issues.apache.org/jira/browse/MCOMPILER-97
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
>Reporter: Jesse N. Glick
>Priority: Major
> Attachments: MCOMPILER-97-workaround.zip, maven-6647998-test.zip
>
>
> It is tricky to compile a Maven module which defines a (269-compliant)
> annotation processor. If you write the code for the processor in
> src/main/java and register it in src/main/resources,
> META-INF/services/javax.annotation.processing.Processor is copied to
> target/classes first, and then javac is run. But javac is given
> target/classes in -classpath, so it tries to load the processor, which of
> course has not been compiled yet - a chicken-and-egg problem.
> The most straightforward workaround is to specify
> -proc:none in your POM. This will only
> work, however, if the module does not use any annotation processors defined
> in dependencies. If it does, there may be some other trick involving
> -processorpath and Maven variable substitution to insert the dependency
> classpath.
> Switching the order of resources:resources and compiler:compile would help -
> at least a clean build would work - though it could still cause problems in
> incremental builds. Better would be for the compiler plugin to pass
> -processorpath based on the dependency classpath (i.e. -classpath minus
> target/classes) when using -source 1.6 or higher.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-336:
--
Fix Version/s: 2.0.0
2.0.0-alpha-7
(was: 4.0.0)
(was: 4.0.0-alpha-7)
> 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
> Fix For: 2.0.0, 2.0.0-alpha-7
>
>
> 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] [Updated] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-336:
--
Fix Version/s: 4.0.0
4.0.0-alpha-7
> 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
> Fix For: 4.0.0, 4.0.0-alpha-7
>
>
> 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=17807354#comment-17807354
]
ASF GitHub Bot commented on MRESOLVER-336:
--
cstamas commented on PR #406:
URL: https://github.com/apache/maven-resolver/pull/406#issuecomment-1894157611
@gnodet @michael-o @rmannibucau any comment?
> 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-1894157611 @gnodet @michael-o @rmannibucau any comment? -- 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)
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
[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
[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)
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] (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] [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=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_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=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_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=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_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=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_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=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 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=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]
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] [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)
[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] [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
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=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]
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=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]
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=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]
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=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)
[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)
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
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
[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]
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=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_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=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" `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=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_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=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 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=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]
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
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
[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)
[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] [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)
