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

Question

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?

If org.myproject changed, why is that not just a version bump for your wrapped bundle? After all, the wrapped contents have changed. — BJ Hargrave
Well if I call it 1.0.2, and then the writers of org.myproject make some changes in addition to the ones I've already included and call that 1.0.2, we're in a bit of a pickle no? If I want to wrap their new version, what version would I call that? — Dan Gravell
Maybe my belief that the bundle version should mirror the wrapped JAR version is incorrect? — Dan Gravell
So you originally wrapped 1.0.1 of org.myproject and called your bundle 1.0.1. Then org.myproject changed but did not increment the version to at least 1.0.2? Then you are in a bit of trouble trying to wrap semantic versions around a projects that does not semantically version. :-( — BJ Hargrave
Yep! ;-) Back to the point - can qualifiers be used in this case, and if so how can I get bnd or bndtools to generate export statements with them in? — Dan Gravell

Peter Kriens Peter Kriens · Accepted Answer · 2016-02-29T10:01:03

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 :-)

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

1 Answers