Hi Hervé,

On 24/09/16 13:46, Hervé BOUTEMY wrote:
if you look at https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
that lead to ComparableVersion [1] implementation: "The current implementation
for version schemes is rather limited. It only supports 5 properties" (and by
"current", it meant DefaultArtifactVersion)

ComparableVersion is meant to be more generic, with any number of parts.

And since DefaultArtifactVersion is not used in core (core only compares
version, does not really need to split in major/minor/...), I never
investigated how it really splits the version string in parts: having a fixed
number of part is broken by design, IMHO, then nobody should use
DefaultArtifactVersion with its broken API. But I never went ahead and removed
this class from core, to avoid incompatibility: perhaps just deprecating this
class would be the most simple thing to do.

So I have marked the class as deprecated...

But it implements an interface:

public interface ArtifactVersion
    extends Comparable<ArtifactVersion>

which should be marked as deprecated as well in consequence of the previous step (my opinion ?) WDYT ?


So one more question:

What about moving DefaultArtifactVersion to maven-compat module...and replace it with a better implementation ?


What might be done is to create an enhanced version of the interface and make a better implemtation (based on ComparableVersion or make same getters to get the parsed information from it...)



Kind regards
Karl Heinz Marbaise



Regards,

Hervé

[1] 
http://maven.apache.org/ref/3-LATEST/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html


Le samedi 24 septembre 2016 12:42:02 Karl Heinz Marbaise a écrit :
Hi to all,

at the moment I'm trying to understand a thing...(motivated by an issue
https://github.com/mojohaus/build-helper-maven-plugin/issues/33)

Lets say I have the following version: "20.4.00.0-SNAPSHOT"

The DefaultArtifactVersion class will parse this version with this result:

artifactVersion.getMajorVersion() = "0"
artifactVersion.getMinorVersion() = "0"
artifactVersion.getIncrementalVersion() = "0"
artifactVersion.getBuildNumber() = "0"
artifactVersion.getQualifier() = "20.4.00.0-SNAPSHOT"

And another version: "20.4.0-SNAPSHOT" and the DefaultArtifactVersion
class will parse this version with this result:

artifactVersion.getMajorVersion() = "20"
artifactVersion.getMinorVersion() = "4"
artifactVersion.getIncrementalVersion() = "0"
artifactVersion.getBuildNumber() = "0"
artifactVersion.getQualifier() = "SNAPSHOT"

but If I do a version comparison via:

java -jar /usr/local/apache-maven-3.3.9/lib/maven-artifact-3.3.9.jar
20.4.00.0-SNAPSHOT 20.4.0-SNAPSHOT
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 20.4.00.0-SNAPSHOT == 20.4-snapshot
    20.4.00.0-SNAPSHOT == 20.4.0-SNAPSHOT
2. 20.4.0-SNAPSHOT == 20.4-snapshot

So the question is why is the first one parsed differently by
DefaultArtifactVersion) than the second one...

Yes I know there is a difference (20.4.00.0...) but from a logical point
of view this does not make sense?

So it looks like that DefaultArtifactVersion follows hardly the pattern:

<majorversion [> . <minorversion [> . <incrementalversion ] ] [> -
<buildnumber | qualifier ]>

whereas the version comparison goes a different path...


Furthermore I have checked some other cases like this:

given Version: 1.2.3-01-SNAPSHOT

artifactVersion.getMajorVersion() = "1"
artifactVersion.getMinorVersion() = "2"
artifactVersion.getIncrementalVersion() = "3"
artifactVersion.getBuildNumber() = "0"
artifactVersion.getQualifier() = "01-SNAPSHOT"

given Version: 1.2.3-01

artifactVersion.getMajorVersion() = "1"
artifactVersion.getMinorVersion() = "2"
artifactVersion.getIncrementalVersion() = "3"
artifactVersion.getBuildNumber() = "0"
artifactVersion.getQualifier() = "01"

Version: 1.2.3-1

artifactVersion.getMajorVersion() = "1"
artifactVersion.getMinorVersion() = "2"
artifactVersion.getIncrementalVersion() = "3"
artifactVersion.getBuildNumber() = "1"
artifactVersion.getQualifier() = null

So this means a buildnumber is not allowed to be prefixed with a digit "0" ?
I think the last two examples look strange to me...I would have expected
that a qualifier is something which starts with a character and not with a
digit...

WDYT ?

Kind regards
Karl Heinz


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to