Le dimanche 16 novembre 2008, Dave Syer a écrit :
> Hervé BOUTEMY wrote:
> > [1]
http://docs.codehaus.org/display/MAVEN/Versioning>
> I didn't see any reference there to special qualifiers.
See "Proposal" section,
"strings are checked for well-known qualifiers and the qualifier ordering is
used for version ordering
* well-known qualifiers (case insensitive)
..."
> But anyway, how
> does it make sense for [1.0.0,2.0.0) (with an *exclusive* upper bound of
> 2.0.0) to include anything from the 2.0.0. branch?
if you don"t want to include anything from the 2.0.0 branch, you have to write
you range as [1.0.0,2.0.0-SNAPSHOT), which is consistent with the versions
ordering (no special case here)
> I don't think users are
> going to expect to pick up pre-production versions of 2.0.0 if they use
> that as an upper exclusive bound.
you're right. They'll have to understand that 2.0.0-alpha1 is before 2.0.0,
then learn the previous way of writing their range to match their need.
If range implementation was cheated to avoid anything from the 2.0.0 branch in
[1.0.0,2.0.0) range, it lets me think we would need more tweak to support
[2.0.0-SNAPSHOT,2.0.0) range, for example.
>
> There is a section on the link above about "define a grammar for version
> specifications".
Yes, the second half of the proposal is about having a pluggable version
comparison, and a super-generic implementation as a configurable component: I
didn't work on that part, only tried to fix the current implementation.
I tried to think about it, but faced problems with this concept of pluggable
version handlers: beside having multiple implementations (or configurations
of a generic one), I don't see at what level pluggability should done:
- at the build level? but components come from a repository, and were build
with their own version scheme
- at the component level? but what if 2 versions of a component specify
different implementations?
> Would it not be sensible to pick up someone else's (rational and
> functional) definition? Maybe the OSGi alliance R4 spec? Many Maven jars
> these days are intended by their author to be used as OSGi bundles, and the
> bundle has a version with a well defined grammar.
This good reasoning has been done by other Maven developers too, independently
from this versioning proposal: for Maven 3.0, there is a full rewrite of
artifact handling in Mercury component with OSGi versioning support: see [1].
> It seems a shame if
> there have to be different version ids for an artifact - it's just
> confising for users. Those jars that are being used as OSGi usually have
> non-Maven version ids already (i.e. in Maven language, not using the same
> qualifiers) because people don't realise that there are any special rules.
State of the art is evolving: a few years ago, OSGi wasn't established as it
is now. Now it is here, it's a major player, but we can't immediately throw
away everything that was done before. Convergence is coming: Tycho for
example tries to fill the gap between Maven and OSGi components. See [2].
Regards,
Hervé
[1]
http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges[2]
http://docs.codehaus.org/display/M2ECLIPSE/Tycho+project+overview---------------------------------------------------------------------
To unsubscribe, e-mail:
[hidden email]
For additional commands, e-mail:
[hidden email]
Locked
