javaosgiversionbndbndtools

Can I use version qualifiers to require specific package versions in OSGi?

I have a third party JAR I wish to wrap - it does not have its own OSGi manifest. For example, org.myproject. So I create a bundle wrapper.

This works fine - I provide the version for the release of org.myproject. This is dictated by the authors of org.myproject. Say, 1.0.1.

Now, org.myproject is changed, and I want to include the changes. However, there's no official release for this. This sounds like I could use a qualifier to represent the newer version: 1.0.1.$timestamp

However, when wrapping the JAR with bndtools, the package exports are still versioned as 1.0.1.

Is it possible to export and then import a qualifier-specific package version in OSGi? What is the best way of managing this in bndtools?

Solution

  • What version are we talking about? If you version a package in bnd with 1.2.3.XXXXX then this is the package version you will get as export.

    However, by default bnd strips the qualifier when it creates the import range based on the export. You should be able to override this with the version policy. The defaults are:

    -provider-policy    = ${range;[==,=+)}
-consumer-policy    = ${range;[==,=+)}

    You can easily change them to include the qualifier.

    However, that would be a global change and I expect you regret this.

    So the other solution is to modify the import of this bad package:

    Import-Package org.myproject;version="${range;[====.=+);${@}}", *

    Of course the easiest solution is to get it over with and accept that putting lip stick on a pig does not make it semantically versioned. Just separate the version from YOUR bundle with the dependency. In those cases I tend to pick a weird major number, e.g. 100, to make clear that my version is NOT the target's version.

    Since I've some nasty memories of those projects I could also advice you to take a look at the OSGi contracts. With contracts you do not version the packages but you use a contract requirement.

    And then the last, and definitely the best, do you real need that project to be versioned? I find that in most cases it is more than worth to develop my own OSGi API that reflects my need of this external target. Then I can leave that package nicely hidden in a dark place where it should probably suffer for not being semantically versioned :-)