You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Dave Syer <da...@hotmail.com> on 2008/11/13 14:09:44 UTC
Version range special cases?
Can anyone explain why the first test succeeds (as expected) but the second
and third fails?
@Test
public void testVanillaVersionRangeExcludesDotQualifier() throws Exception
{
VersionRange range = VersionRange.createFromVersionSpec("[1.0.0,2.0.0)");
assertFalse(range.containsVersion(new
DefaultArtifactVersion("2.0.0.RELEASE")));
}
@Test
public void testVanillaVersionRangeExcludesDotQualifierMilestone() throws
Exception {
VersionRange range = VersionRange.createFromVersionSpec("[1.0.0,2.0.0)");
// Fails even in Maven 3.0
assertFalse(range.containsVersion(new
DefaultArtifactVersion("2.0.0.M1")));
}
@Test
public void testVanillaVersionRangeExcludesDotQualifierReleaseCandidate()
throws Exception {
VersionRange range = VersionRange.createFromVersionSpec("[1.0.0,2.0.0)");
// Fails even in Maven 3.0
assertFalse(range.containsVersion(new
DefaultArtifactVersion("2.0.0.RC1")));
}
It seems like there is some weird special case hard wired to recognise "M"
and "RC" as special prefixes (and do the wrong thing with them - as far as I
can see).
This is with 3.0-alpha-2-SNAPSHOT version of maven-artifact.
--
View this message in context: http://www.nabble.com/Version-range-special-cases--tp20480510p20480510.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version range special cases?
Posted by Michael McCallum <gh...@apache.org>.
On Mon, 17 Nov 2008 00:43:03 Dave Syer wrote:
>
> Michael McCallum-3 wrote:
> >
> > just start at 2.1 and everything just works and makes sense...
> >
>
> Sorry, not to me, and not to anyone I know who uses version ranges. The
works or make sense ;-)
> OSGi version conventions always used to annoy me. Now I've found something
> even worse. Why don't we just adopt the same rules - at least they are
> sane, and proven in production use?
I used that approach with a rather transition team of consultants for production of 9 complex deliverables
of over 150 artifacts. Worked fine for us.
>
> If 2.0.0 is the upper exclusive bound, I definitely do not want 2.0.0-* to
> be included. It's completely counter intuitive.
Maybe I'm be a bit too pure with my math but when you say to but not include thats everything up to and
not including... how is that not intuitive?
In any case as long as [1,2) incluedes 1.1-SNAPSHOT and exlucdes 2.1-SNAPSHOT at the end of the day I will be happy...
so I'll stop arguing
btw: Gentoo linux solves this problem with slots [1] ... the 'pom' specifies a slot it belongs in e.g. 1, 2, 1.5 etc and things can depend on a particular slot.
cheers
[1] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#doc_chap4
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version range special cases?
Posted by Dave Syer <da...@hotmail.com>.
Michael McCallum-3 wrote:
>
> just start at 2.1 and everything just works and makes sense...
>
Sorry, not to me, and not to anyone I know who uses version ranges. The
OSGi version conventions always used to annoy me. Now I've found something
even worse. Why don't we just adopt the same rules - at least they are
sane, and proven in production use?
If 2.0.0 is the upper exclusive bound, I definitely do not want 2.0.0-* to
be included. It's completely counter intuitive.
--
View this message in context: http://www.nabble.com/Version-range-special-cases--tp20480510p20524459.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version range special cases?
Posted by Michael McCallum <gh...@apache.org>.
On Sun, 16 Nov 2008 21:51:18 Dave Syer wrote:
>
> Hervé BOUTEMY wrote:
> >
> > [1] http://docs.codehaus.org/display/MAVEN/Versioning
> >
>
> I didn't see any reference there to special qualifiers. 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? 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.
Its really really obvious but somewhat anoyying...
2-SNAPHOT == 2.0.0-SNAPSHOT < 2.0.0
therefore
,2.0.0) is up to but not including 2.0.0
unfortunately including 2.0.0-SNAPSHOT
but it makes sense, the only other option is to have a special case that not having
a qualifier means 2.0.0-SNAPSHOT in a non-exclusive bound and thats just *arse*
THE SOLUTION IS TO NEVER USE 2.0
just start at 2.1 and everything just works and makes sense... and why not use natural numbering
anyway its more elegant... get rid of this odd development termininology of 0 versions.
my 2c
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version range special cases?
Posted by Oleg Gusakov <ol...@gmail.com>.
Hervé BOUTEMY wrote:
>> 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].
>
>
In Mercury I addressed it with having a VersionRangeFactory.create(
String version, QualityRange qRange ), the qRange defines a Quality
interval created out of [snapshot, alpha, beta and release] enumeration
for the version range upper boundary. Only quality that's inside the
specified interval is allowed to participate in version range
evaluation. Default behavior is to allow all.
I envision that in the future we'll replace enumeration with an
arbitrary, user defined sequence of code quality descriptors.
OSGi interpretation of ranges is default, with the exception of a single
version: by default "2.4" is interpreted as a "soft" range in the
dependency tree resolution - (,), but with and option it's possible to
switch to OSGi compliant [2.4,)
Hope this helps,
Oleg
Re: Version range special cases?
Posted by Hervé BOUTEMY <he...@free.fr>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version range special cases?
Posted by Dave Syer <da...@hotmail.com>.
Hervé BOUTEMY wrote:
>
> [1] http://docs.codehaus.org/display/MAVEN/Versioning
>
I didn't see any reference there to special qualifiers. 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? 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.
There is a section on the link above about "define a grammar for version
specifications".
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. 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.
--
View this message in context: http://www.nabble.com/Version-range-special-cases--tp20480510p20523441.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version range special cases?
Posted by Hervé BOUTEMY <he...@free.fr>.
yes, there are special cases hardwired, that were not meant to be weird but
useful features added to Maven Artifact 3.0 :)
see the proposal [1], the current implementation [2] and test-case [3]
the rationale is that snapshot < alpha < beta < milestone < release candidate
< release < service pack
regards,
Hervé
[1] http://docs.codehaus.org/display/MAVEN/Versioning
[2]
http://svn.apache.org/viewvc/maven/artifact/trunk/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java?view=markup
[3]
http://svn.apache.org/viewvc/maven/artifact/trunk/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java?view=markup
Le jeudi 13 novembre 2008, Dave Syer a écrit :
> Can anyone explain why the first test succeeds (as expected) but the second
> and third fails?
>
> @Test
> public void testVanillaVersionRangeExcludesDotQualifier() throws Exception
> {
> VersionRange range = VersionRange.createFromVersionSpec("[1.0.0,2.0.0)");
> assertFalse(range.containsVersion(new
> DefaultArtifactVersion("2.0.0.RELEASE")));
> }
>
> @Test
> public void testVanillaVersionRangeExcludesDotQualifierMilestone() throws
> Exception {
> VersionRange range = VersionRange.createFromVersionSpec("[1.0.0,2.0.0)");
> // Fails even in Maven 3.0
> assertFalse(range.containsVersion(new
> DefaultArtifactVersion("2.0.0.M1")));
> }
>
> @Test
> public void testVanillaVersionRangeExcludesDotQualifierReleaseCandidate()
> throws Exception {
> VersionRange range = VersionRange.createFromVersionSpec("[1.0.0,2.0.0)");
> // Fails even in Maven 3.0
> assertFalse(range.containsVersion(new
> DefaultArtifactVersion("2.0.0.RC1")));
> }
>
> It seems like there is some weird special case hard wired to recognise "M"
> and "RC" as special prefixes (and do the wrong thing with them - as far as
> I can see).
>
> This is with 3.0-alpha-2-SNAPSHOT version of maven-artifact.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org