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.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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
