Le samedi 24 septembre 2016 17:33:31 Karl Heinz Marbaise a écrit :
> 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 ?
+1
the issue is both in interface and implementation

> 
> 
> So one more question:
> 
> What about moving DefaultArtifactVersion to maven-compat module...
good idea
> and replace it with a better implementation ?
if you can improve it, why not

> 
> 
> 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...)
yes, adding getters in ComparableVersion would be a good idea
the only issue is that I fear that nobody will use it, since it would require 
Maven 3.4

Regards,

Hervé

> 
> 
> 
> Kind regards
> Karl Heinz Marbaise
> 
> > Regards,
> > 
> > Hervé
> > 
> > [1]
> > http://maven.apache.org/ref/3-LATEST/maven-artifact/apidocs/org/apache/ma
> > ven/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


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

Reply via email to