Felix
  1. Felix
  2. FELIX-2972

Treatment of version ranges seems incorrect.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: maven-bundle-plugin-2.3.4
    • Fix Version/s: None
    • Component/s: Maven Bundle Plugin
    • Labels:
      None

      Description

      I have a sample project which specifies a dependency on
      <dependency>
      <groupId>javax.jdo</groupId>
      <artifactId>jdo-api</artifactId>
      <version>[3.0, )</version>
      <scope>provided</scope>
      </dependency>

      and there is a version 3.0, 3.1-SNAPSHOT-20110319, 3.1-SNAPSHOT-20110223 in the specified respositories.

      I generate the MANIFEST.MF and it gives an ImportPackage of

      Import-Package: javax.jdo;version="[3.1,4)", ...

      It seemingly just grabs the latest current version available in the repositories in that range and takes that as the OSGi start version. This is incorrect, since a user could have v3.0 on their system and deploy that into OSGi and it doesn't allow deployment of this project. Or is it doing something deeper?

      1. bundle_test.zip
        6 kB
        Andy Jefferson

        Activity

        Hide
        Andy Jefferson added a comment -

        Sample maven project that has the issue. Just run "mvn clean install"

        Show
        Andy Jefferson added a comment - Sample maven project that has the issue. Just run "mvn clean install"
        Hide
        Guillaume Nodet added a comment -

        The maven bundle plugin does not really use version ranges expressed in maven. Actually, I'm not even sure we can access those as one of the first thing maven will do will be to resolve those ranges to exact versions. If you want to generate [3.0,4), you can simply depend on the 3.0 version in maven and it will work. I guess the problem is that maven tends to resolve to the highest possible version instead of the lowest.

        Show
        Guillaume Nodet added a comment - The maven bundle plugin does not really use version ranges expressed in maven. Actually, I'm not even sure we can access those as one of the first thing maven will do will be to resolve those ranges to exact versions. If you want to generate [3.0,4), you can simply depend on the 3.0 version in maven and it will work. I guess the problem is that maven tends to resolve to the highest possible version instead of the lowest.
        Hide
        Stuart McCulloch added a comment -

        This is working as designed from the perspective of the maven-bundle-plugin and bnd. If you build with "mvn clean install -X" you will see that Maven chose to compile the code against "jdo-api-3.1-SNAPSHOT". Therefore the baseline import version is "3.1", because that is what the code was compiled and tested against. Generally with OSGi you always want to compile against the earliest versions you plan to support.

        But you can select a different default version policy if you want to compile against a dependency with version "3.1" but still declare compatibility with "3.0" as well:

        <_versionpolicy>[$(version;=;$(@)),$(version;+;$(@)))</_versionpolicy>

        See http://www.aqute.biz/Bnd/Versioning and http://www.aqute.biz/Bnd/Format#import-package for more details. Note that in addition to the "-versionpolicy" instruction, the latest versions of bnd also support separate "-provider-policy" and "-consumer-policy" instructions since you often need different policies when providing vs. consuming an interface.

        Show
        Stuart McCulloch added a comment - This is working as designed from the perspective of the maven-bundle-plugin and bnd. If you build with "mvn clean install -X" you will see that Maven chose to compile the code against "jdo-api-3.1-SNAPSHOT". Therefore the baseline import version is "3.1", because that is what the code was compiled and tested against. Generally with OSGi you always want to compile against the earliest versions you plan to support. But you can select a different default version policy if you want to compile against a dependency with version "3.1" but still declare compatibility with "3.0" as well: <_versionpolicy>[$(version;=;$(@)),$(version;+;$(@)))</_versionpolicy> See http://www.aqute.biz/Bnd/Versioning and http://www.aqute.biz/Bnd/Format#import-package for more details. Note that in addition to the "-versionpolicy" instruction, the latest versions of bnd also support separate "-provider-policy" and "-consumer-policy" instructions since you often need different policies when providing vs. consuming an interface.

          People

          • Assignee:
            Stuart McCulloch
            Reporter:
            Andy Jefferson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development