OSGI Bundle Dependency Resolution Issue due to Version numbers

YOIu need to make sure you are referencing the correct version. When you update the version of A, you need to make sure B is referencing the modified version. General OSGi concepts like this can be found here -

2.2 OSGi Concepts .

Hi,

The important thing on bundle version is, that they are not that relevant. Important are the package versions the provide or require.

In your case the problem is the "optional". It means that a dependency is optional, and the bundle will get active even if the requested package in the proper version is not present. If that's a mandantory (non-optional) dependency the bundle will stay on installed until the dependency gets resolved.

You declare a dependency optional when your application can handle the case of non-present code itself. In most cases you don't want to deal with that yourself and let the container handle it for you, and then you choose mandantory dependencies.

To your case: It worked as long as the optional dependency has been resolved; now that package is no longer present and your code cannot handle it. Remove that optional and your bundle should not get active anymore. Or fix the code to make it work without that package being present.

cheers,

Jörg

Thanks smacdonald2008​,

I have tried this Import-Package option with a version range [1.0.0,10.0.0), however when we build the bundle & deploy it the bundle manifest headers import package still shows [1.X,2). Looks like the mainfest headers are generated based on the latest version of the dependency which is currently in the maven repository.

What we are actually looking at is once Project B is deployed to AEM, it should resolve any future version of Project A automatically(Without having to build & redeploy ProjectB). Is that possible?

For now, we are rebuilding Project B and deploying every time we increment ProjectA version number.

Thanks Jörg Hoh​,

I have tried removing resolution=optional which makes the bundle to installed state. Can you please provide some more details on the below point? Do you mean to say embedding dependency using <Embed-Dependency> option?

"Or fix the code to make it work without that package being present."

Embedding the dependency is the wrong approach, unless it's a third party library, which is not available as OSGI bundle.

The manifest headers are build against the package version of the bundles you specified in the pom.xml. And that's the reason why the OSGI community pays so much attention on proper versioning of their bundles.

So solve your problem, build and deploy the project B in a version 1.0; and then add it as a dependency to project A. And whenever you build project A, build against project B with B having the version 1.0. I do that daily and it works flawlessly.

Jörg