Maven 2.x Eclipse Plugin

eclipse:to-maven uses version ranges in pom.xmls created, which fail version checking

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.5.1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP SP3, Maven 2.0.9, Java 1.6.0.11
  • Number of attachments :
    0

Description

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.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ken Stevens added a comment -

There are hundreds of posts on the internet about this problem. Please raise the priority. Google for:

Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0)
org.eclipse.equinox:app:jar:null

Show
Ken Stevens added a comment - There are hundreds of posts on the internet about this problem. Please raise the priority. Google for: Couldn't find a version in [1.0.0-v20070606] to match range [1.0.0,2.0.0) org.eclipse.equinox:app:jar:null
Hide
Permalink
Adrian Wilkins added a comment -

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.

Show
Adrian Wilkins added a comment - 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.
Hide
Permalink
Thomas Ferris Nicolaisen added a comment -

Maven 3 will probably resolve this: http://docs.codehaus.org/display/MAVEN/Versioning

For Maven 2, perhaps the the to-maven goal could generate Eclipse artifacts with a build-number integer (based on checksum or something). Just an idea, so we don't have to fiddle with 100 excludes..

Show
Thomas Ferris Nicolaisen added a comment - Maven 3 will probably resolve this: http://docs.codehaus.org/display/MAVEN/Versioning For Maven 2, perhaps the the to-maven goal could generate Eclipse artifacts with a build-number integer (based on checksum or something). Just an idea, so we don't have to fiddle with 100 excludes..

People

  • Assignee:
    Unassigned
    Reporter:
    Costin Caraivan
Vote (4)
Watch (2)

Dates

  • Created:
    Updated: