Well, I made the change and all the IT tests pass. I'm not surprised because 
when I searched for the use of that VersionRange.contains() it's only used in 
one place, so it's entirely likely this is not working and no one noticed.

It's easy to tweak my patch so that contains treats "2.0.5" == "[2.0.5,)", I 
just need to change =0 to >=0 because I use the compareto() method for singular 
versions. Which should it be? The alternative is I just take this contains code 
and move it into my plugin to work correctly, but that doesn't do much to solve 
the real problem.

-----Original Message-----
From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 8:46 AM
To: Maven Developers List
Subject: Re: version range question



Brian E. Fox wrote:
> The problem is that I assumed "2.0.5" == "[2.0.5,)". I can understand how it 
> is when I see it and I can work with that. The problem now is that 
> createFromVersionSpec doesn't create any restrictions and 
> restrictions.contains returns true by default. If I add the test as shown 
> below, it fails here:        assertFalse( enforceVersion( "2.0.6", 
> actualVersion ) );
> 
> This is saying that 2.0.6 contains 2.0.5 which should be false.

Indeed, my last statement wasn't entirely correct.

"2.0.6" is not "[2.0.6,)". It's merely a suggestion. In maven, the closest 
dependency
wins, even if it's an older version. The "2.0.6" is treated as a 'recommended 
version',
not the lower limit. So if you want to force versions to be 'at least X',
you'll have to specify <version>[X,)</version>. 
I know that's what people *think* <version>X</version> means, but it doesn't.

I'm not sure if we can change this - a lot of builds will fail, though it'll 
certainly
meet expectations better.

-- Kenney

> 
>     public void testContains() throws InvalidVersionSpecificationException
>     {
>         ArtifactVersion actualVersion = new DefaultArtifactVersion( "2.0.5" );
>         assertTrue( enforceVersion( "2.0.5", actualVersion ) );
>         assertTrue( enforceVersion( "2.0.4", actualVersion ) );
>         assertTrue( enforceVersion( "[2.0.5]", actualVersion ) );
>         assertFalse( enforceVersion( "2.0.6", actualVersion ) );
>         assertFalse( enforceVersion( "[2.0.6]", actualVersion ) );
>         assertTrue( enforceVersion( "[2.0,2.1]", actualVersion ) );
>         assertFalse( enforceVersion( "[2.0,2.0.3]", actualVersion ) );
>         assertTrue( enforceVersion( "[2.0,2.0.5]", actualVersion ) );
>         assertFalse( enforceVersion( "[2.0,2.0.5)", actualVersion ) );
>     }
> 
>     public boolean enforceVersion( String requiredVersionRange, 
> ArtifactVersion actualVersion )
>         throws InvalidVersionSpecificationException
>     {
>         VersionRange vr = null;
> 
>         vr = VersionRange.createFromVersionSpec( requiredVersionRange );
> 
>         return vr.containsVersion( actualVersion );
>     }
> 
> 
> 
> -----Original Message-----
> From: Kenney Westerhof [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 15, 2007 5:45 AM
> To: Maven Developers List
> Subject: Re: version range question
> 
> I'm sorry, what is the problem exactly?
> 
> createFromVersionSpec: treats version as a version range, so 2.0.5 is treated
> as [2.0.5,).
> 
> createFromVersion: treats version as a single pinned version, so 2.0.5 is 
> treated
> as [2.0.5].
> 
> So, createFromVersionSpec("2.0.5").containsVersion( new 
> DefaultArtifactVersion("2.0.6") )
> is true since 2.0.6 is in [2.0.5,).
> 
> Or am I missing something here?
> 
> -- Kenney
> 
> Brian E. Fox wrote:
>> Done. I fixed the problem and added the tests to a branch described
>> here: http://jira.codehaus.org/browse/MNG-2876
>>
>> Since it's very core (or maybe not if it's not really used) I'd like
>> someone to bless it.
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
>> Sanchez
>> Sent: Wednesday, March 14, 2007 1:06 AM
>> To: Maven Developers List
>> Subject: Re: version range question
>>
>> I would create a jira issue with your tests as unit tests
>>
>> then search for usages of createFromVersionSpec through the whole
>> maven and see how it's used
>>
>> On 3/13/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>>> I'm still having trouble with this. I wrote a sample class to show my
>>> problem. The issue is that all the contains calls are correct except
>>> that a singular version ie "2.0.5" always returns true. Is this an
>>> artifact bug, or am I doing something wrong? According to the javadoc
>>> for the method (shown in my original post below) the singular version
>> is
>>> allowed as a version range.
>>>
>>> Output:
>>> is 2.0.5 contained in 2.0.5 ->true      CORRECT
>>> is 2.0.5 contained in 2.0.6 ->true      WRONG
>>> is 2.0.5 contained in [2.0,2.1] ->true CORRECT
>>> is 2.0.5 contained in [2.0,2.0.3] ->false CORRECT
>>> is 2.0.5 contained in [2.0,2.0.5] ->true CORRECT
>>> is 2.0.5 contained in [2.0,2.0.5) ->false CORRECT
>>> Source:
>>> /**
>>>  *
>>>  */
>>> package org.apache.maven.plugin.enforcer;
>>>
>>> import org.apache.maven.artifact.versioning.ArtifactVersion;
>>> import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
>>> import
>>>
>> org.apache.maven.artifact.versioning.InvalidVersionSpecificationExceptio
>>> n;
>>> import org.apache.maven.artifact.versioning.VersionRange;
>>> import org.apache.maven.plugin.MojoExecutionException;
>>> import org.apache.maven.plugin.MojoFailureException;
>>>
>>> /**
>>>  * @author brianf
>>>  *
>>>  */
>>> public class test
>>> {
>>>     public static void main( String[] args )
>>>         throws MojoExecutionException, MojoFailureException,
>>> InvalidVersionSpecificationException
>>>     {
>>>         ArtifactVersion actualVersion = new DefaultArtifactVersion(
>>> "2.0.5" );
>>>         enforceVersion( "2.0.5", actualVersion );
>>>         enforceVersion( "2.0.6", actualVersion );
>>>         enforceVersion( "[2.0,2.1]", actualVersion );
>>>         enforceVersion( "[2.0,2.0.3]", actualVersion );
>>>         enforceVersion( "[2.0,2.0.5]", actualVersion );
>>>         enforceVersion( "[2.0,2.0.5)", actualVersion );
>>>     }
>>>
>>>     public static void enforceVersion( String requiredVersionRange,
>>> ArtifactVersion actualVersion )
>>>         throws MojoExecutionException, MojoFailureException,
>>> InvalidVersionSpecificationException
>>>     {
>>>         VersionRange vr = null;
>>>
>>>         vr = VersionRange.createFromVersionSpec( requiredVersionRange
>> );
>>>         boolean result = vr.containsVersion( actualVersion );
>>>         System.out.println( "is "+actualVersion+" contained in
>>> "+requiredVersionRange+" ->" + result );
>>>     }
>>> }
>>>
>>> -----Original Message-----
>>> From: Brian E. Fox [mailto:[EMAIL PROTECTED]
>>> Sent: Sunday, February 18, 2007 8:15 PM
>>> To: Maven Developers List
>>> Subject: version range question
>>>
>>> According to the javadoc for VersionRange.createFromVersionSpec, a
>>> singular version (ie "2.0.4") is allowed:
>>>
>>>
>>>
>>> /**
>>>
>>>      * Create a version range from a string representation
>>>
>>>      *
>>>
>>>      * Some spec examples are
>>>
>>>      * <ul>
>>>
>>>      *   <li><code>1.0</code> Version 1.0</li>
>>>
>>>      *   <li><code>[1.0,2.0)</code> Versions 1.0 (included) to 2.0
>> (not
>>> included)</li>
>>>
>>>      *   <li><code>[1.0,2.0]</code> Versions 1.0 to 2.0 (both
>>> included)</li>
>>>
>>>      *   <li><code>[1.5,)</code> Versions 1.5 and higher</li>
>>>
>>>      *   <li><code>(,1.0],[1.2,)</code> Versions up to 1.0 (included)
>>> and 1.2 or higher</li>
>>>
>>>      * </ul>
>>>
>>>      *
>>>
>>>      * @param spec string representation of a version or version range
>>>
>>>      * @return a new [EMAIL PROTECTED] VersionRange} object that represents 
>>> the
>>> spec
>>>
>>>      * @throws InvalidVersionSpecificationException
>>>
>>>      */
>>>
>>>
>>>
>>> However, if I create a version range using
>>> createFromVersionSpec("2.0.4") and then call,
>> vr.containsVersion(2.0.5)
>>> the result is true. However, if I use createFromVersion("2.0.4") and
>>> then use vr.containsVersion("2.0.5"), I get the expected false.
>>>
>>>
>>>
>>> So is this a bug in the Spec method? What is the difference between
>> the
>>> two supposed to be? It seems like the fromVersion method can handle
>> the
>>> spec strings also so I'm confused why there are two.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to