You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Adrian Wilkins (JIRA)" <ji...@codehaus.org> on 2009/11/14 01:40:55 UTC

[jira] Commented: (MECLIPSE-531) eclipse:to-maven uses version ranges in pom.xmls created, which fail version checking

    [ http://jira.codehaus.org/browse/MECLIPSE-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198287#action_198287 ] 

Adrian Wilkins commented on MECLIPSE-531:
-----------------------------------------

I think this is a problem with the mismatch between the way that Maven uses version numbers and everything else does.

Maven uses a -SNAPSHOT or similar suffix to indicate versions earlier than that in the main version number. Everything else seems to use this to indicate later versions (Eclipse being one of these things).

So Eclipse is using the qualifier (fourth segment) to mark versions AFTER the version number incremented, Maven is taking the fourth segment to be versions BEFORE the version number incremented.

>From "DefaultArtifactVersion.java"

// otherVersion has a qualifier but we don't, we're newer

The fourth segment in Eclipse version numbers doesn't correspond to the same thing as Mavens "qualifier" even if it's called the same thing. It's more like "build number" (which is currently required to be an integer in Maven, so that would have to change to support this).

Stripping qualifiers is probably the only short-term fix. If the modules in question are following the version numbering policy there should be no API breaks ; the downside is that your repository may end up holding older versions of some components. You should probably run eclipse:to-maven after each Eclipse update, into a central repository if there is more than one person working on the project.

I think a real fix for this would be to permit arbitrary strings in the "build number" field on DefaultArtifactVersion class, although this will complicate it very slightly ; then you'd have to fix the eclipse:to-maven mojo to put eclipse-qualifier in the build number field where it should be, instead of the maven-qualifier field where it stops things working.

I'm going to delete my "eclipse" repository hierarchy and run it again with stripped qualifiers now. Bah.

> eclipse:to-maven uses version ranges in pom.xmls created, which fail version checking
> -------------------------------------------------------------------------------------
>
>                 Key: MECLIPSE-531
>                 URL: http://jira.codehaus.org/browse/MECLIPSE-531
>             Project: Maven 2.x Eclipse Plugin
>          Issue Type: Improvement
>    Affects Versions: 2.5.1
>         Environment: Windows XP SP3, Maven 2.0.9, Java 1.6.0.11
>            Reporter: Costin Caraivan
>
> If you use eclipse:to-maven, the resulting artifacts have poms containing versions like these, for dependencies: [3.2.0,4.0.0).
> End result =>
> Couldn't find a version in [3.2.0-v3232o] to match range [3.2.0,4.0.0)
> I believe that to-maven needs an option like make-artifacts, to resolveVersionRanges, because stripping qualifiers means that we lose information (Eclipse 3.4 has some 3.2.0 plugins for example, but with a different qualifier than the original 3.2 Eclipse plugins).
> Or the version ranges need to be fixed, something like this: [3.2.0-, 4.0.0-).
> Thank you.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira