Multiple bundle versions deployed in one OSGi instance

Question

I have three applications deployed in CQ which all depend on one bundle (say 'core').

Core is undergoing a major face lift and there is a requirement to define the dependency of all three application on different versions of core, e.g.

• A will have dependency on core 1.0
• B will have dependency on core 1.5
• C will have dependency on core 2.0

Is it possible to do this?

Farflung

Answer 1

OSGi (which CQ itself is embedded in) supports multiple versions of packages deployed at the same time. You could deploy the 3 versions of 'core' and then request a specific version in your Manifest for the importing applications:

Bundle A

Import-Package: package.name.of.core;version="1.0"

Bundle B

Import-Package: package.name.of.core;version="1.5"

Bundle C

Import-Package: package.name.of.core;version="2.0"

If you're using the Maven Bundle plugin, you can do the same via your bundle's POM to generate the correct Manifest headers:

<dependency>
    <groupId>group.of.core</groupId>
    <artifactId>core</artifactId>
    <version>2.0.0</version>
</dependency>

---

You could supply a bound version range in your Manifest, e.g.

Bundle A

Import-Package: package.name.of.core;version="[1.0,1.1)"

Bundle B

Import-Package: package.name.of.core;version="[1.5,1.6)"

Bundle C

Import-Package: package.name.of.core;version="[2.0,3.0)"

Bundle C (via POM)

<dependency>
    <groupId>group.of.core</groupId>
    <artifactId>core</artifactId>
    <version>[2.0.0,3.0.0)</version>
</dependency>

This would allow you to inherit bug fixes for example — if the deployed version changed to 2.0.1, you wouldn't need to recompile & redeploy Bundle C.

• The open-square bracket [i.e. [ ] above tells the bundle to accept from the first version provided.
• The closing bracket [i.e. ) ] tells it accept up to but excluding the second version provided.

As a side note, if your dependencies are controlling their own versioning correctly (i.e. following semantic versioning), you should always be able to supply a range for the version — from the current version up to the next major release.

I.e. in your case, Application A should also be able to use version 1.5, as a minor release shouldn't contain breaking changes in terms of backwards compatibility.

Pyrrhonism