I think it makes more sense to let 2.0.5 mean [2.0.5,), not [2.0.5].
If you'd do the latter we'd definitely have a problem. There are lots of
places where maven-model 2.0 is used, and also lots of places where 2.0.3 or 
later
is used. Having this restriction will cause maven's build to fail..

So I'd try restriction(process, true, null, false)..

Brian E. Fox wrote:
I'll try doing that. Strictly speaking though, I think the only thing
that makes sense is 2.0.5 = [2.0.5]. In fact, the javadoc for
createFromVersionSpec says this:<li><code>1.0</code> Version 1.0</li>.
Also, when you think about this class by itself, we are testing a range.
How maven decides to handle the results of that test are separate from
how this object should behave. That being said, I do agree we need to be
carefull.

My patch only fixes the contains method because I couldn't fix the
construction of the restrictions without breaking other tests, even
though I believe the root of the problem is the restriction created. The
code is quite clear here:
            else
            {
                version = new DefaultArtifactVersion( process );
                restrictions.add( Restriction.EVERYTHING );
            }
That the intent is to include everything for a singular version. I think
this should be
            else
            {
                version = new DefaultArtifactVersion( process );
                restrictions.add( new
Restriction(process,true,process,true) }

But doing this breaks other unit tests.

I'll make an IT test and see what happens just patching the contains
method.

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



Brian E. Fox wrote:
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 could very well be that there's no it for it.
Try creating one with this structure:

ROOT/
  A/ dep on FOO 1.0 and B
  B/ dep on C
  C/ dep on FOO 2.0

FOO can be any artifact where a class exists in 2.0 but not in 1.0.
For instance plexus-utils 1.0 and a later version. C should use a class in FOO 2.0 that's not there in 1.0.

Then maven _should_ use FOO 1.0 for A, B and C, causing C not to
compile, if your patch is applied. Otherwise, the patch isn't good
enough probably becuase there's other code that does not honor 2.0.5 NOT
being in 2.0.6...

-- Kenney

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.InvalidVersionSpecificationExce
ptio
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]


---------------------------------------------------------------------
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