Jukka Zitting wrote:
> Hi,
>
> On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor <m...@schor.com> wrote:
>   
>> With this change, we can remove all references to a special Eclipse
>> repository location.  I'm in favor of this; what do others think?
>>     
>
> Sounds good. Is there a reason why you use a version range instead of
> one specific version?
>   
The original reason I think is to allow different versions of Eclipse to
be used.  But, since this "provided", meaning that the jar is not
included, but instead comes from the Eclipse environment in which the
jar runs, I think it we could use just single versions. 

Nevertheless, coding a version range here serves to document that the
intention is that the plugin "should" work within that version range.

I tried the following:

        <dependency>
            <groupId>org.eclipse.swt.win32.win32</groupId>
            <artifactId>x86</artifactId>
            <version>3.3.0</version>             <<<<<<<< Fails
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.eclipse.swt.win32.win32</groupId>
            <artifactId>x86</artifactId>
            <version>3.2.9</version>             <<<<<<<< Fails
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.eclipse.swt.win32.win32</groupId>
            <artifactId>x86</artifactId>
            <version>3.3.0-v3346</version>             <<<<<<<< Works
            <scope>provided</scope>
        </dependency>

So, if we go with a fixed version number, it has to include the -XXXXXX
part of the version in order to match.

----------------------------------
    READ THIS NEXT PART !
----------------------------------
Now, for the interesting part.  Maven appears to have *partially* fixed
this problem.  If you type

mvn dependency:tree

for this project, you will see that maven is able to
find/locate/download transitive dependencies.  To do this it is locating
these where the POMs for the components having the dependencies specify
them using the [3.3.0,4.0.0) syntax.  Here's an example.

The uimaj-ep-cas-editor project depends on org.eclipse.jface:text and
gets version 3.3.0-v20070606-0010

In maven central repo that pom
 
http://repo1.maven.org/maven2/org/eclipse/jface/text/3.3.0-v20070606-0010/text-3.3.0-v20070606-0010.pom
has a dependency on org.eclipse:text which is resolved to version
3.3.0-v20070606-0010, but which is specified as
 
<dependency>
  <groupId>org.eclipse</groupId>
  <artifactId>text</artifactId>
  <version>[3.3.0,4.0.0)</version>
</dependency>

So - they've changed (fixed) the comparison in maven for *transitive*
version specs, it seems.

-Marshall
> Maven policy is pretty good at ensuring that a single released version
> never changes, but if you explicitly use a version range for a
> dependency, it's impossible to say for sure which version gets
> included in the build.
>
> BR,
>
> Jukka Zitting
>
>
>   

Reply via email to