Maven Eclipse Plugin
  1. Maven Eclipse Plugin
  2. MECLIPSE-531

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

        Hide
        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
        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
        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
          • Votes:
            4 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: