maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Wilkins (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MECLIPSE-531) eclipse:to-maven uses version ranges in pom.xmls created, which fail version checking
Date Sat, 14 Nov 2009 00:40:55 GMT

    [ 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

        

Mime
View raw message