Search code examples
aemosgi-bundle

Multiple bundle versions deployed in one OSGi instance

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?

Solution

  • 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.