Hi,

we have a kind of strange version mechanism, and I wonder I can 'translate'
this to maven.

This is how it works:
E1.01.01
E1.01.02
..
V1.01

Versions starting with E are test builds leading into the release (V1.01 in
the example)

Is 1.01 considered newer then 1.01-E01 for example?

regards,

Wim

2008/9/5 Benjamin Smith-Mannschott <[EMAIL PROTECTED]>

>
> On Sep 4, 2008, at 22:09, Stephen Connolly wrote:
>
>  On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott:
>>
>>> Yes. That helped, as did
>>> http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
>>>
>>> Which actually comes out and says that qualifier and build nr are
>>> mutually
>>> exclusive. The syntax given says this too, but I wasn't seeing it.
>>> Another
>>> way of looking at it, I suppose, is that everything following "1.2.3-" is
>>> taken as single qualifier, which is compared numerically if it happens to
>>> be
>>> composed only of digits and otherwise compared as a string.
>>>
>>
>>
>> Yep:
>>
>>
>> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#155
>>
>>
> Aha! thanks! I was grubbing around in the source of the 2.0.x branch
> yesterday after I wrote my message looking for exactly this class, only I
> didn't find it. ;-)
>
>
>>> It seems that '.2.3', in the example above is optional, those parts taken
>>> to be zero if missing. If any alphanumerics get mixed up in there or
>>> about
>>> without a separating hyphen the whole thing goes textual and is just
>>> compared as a single string. At least that's what I understood.  So
>>> presumably, if we're comparing two version strings with eachother and one
>>> is
>>> "well formed" and the other is not, they just get compared as if they
>>> were
>>> both not well formed.
>>>
>>
>>
>> Nope:
>>
>>
>> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#54
>>
>> If one is treated as a string (because it's malformed) the other will
>> always
>> be newer (because it has a build number)
>>
>
> Actually, it looks like the build number only enters into it when both have
> a build number, but build number and qualifier are mutually exclusive, so
> the logic exits early if one has a qualifier and the other doesn't.
>
> Somehow that logic makes me a little queezy, but at least it does appear to
> sort consistently.
>
>
> // Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to