Exported Package Versions

[kierann]

With dm Server 2.0.1.RELEASE: I'm having an issue with Import-Package not always selecting the latest revision of a bundle if the exported packages of the bundle weren't explicitly versioned in its manifest.

I've switched to using a hosted repository that houses all the continuous integration builds of my software, but now different bundles that require the same package (say both have the line Import-Package: app.inf;version="[1.0.0,2.0.0)") are importing different builds of the required bundle (say 1.0.0.CI00010 and 1.0.0.CI00009).

In one instance I even had one bundle, with two imported packages, use one build (app.inf 1.0.0.CI00005) for one package and a different build (app.inf 1.0.0.CI00004) for another.

Is this because without the "version" set on the Export-Package entries, they default to 0.0.0 and dm Server just randomly picks a bundle to satisfy the package?

[Glyn Normington]

I'm confused. Import-Package: app.inf;version="[1.0.0,2.0.0)" will never wire to version 0 of the app.inf package.

Please can you clarify?

[kierann]

Sorry, my mistake. Import-Package doesn't have a version range set. I have two bundles importing the same packages:

Bundle A: Import-Package: app.inf
Bundle B: Import-Bundle: app.bundle;version="[1.0.0,2.0.0)"

Where app.bundle has:
Bundle-SymbolicName: app.bundle
Bundle-Version: 1.0.0 (with CI# appended to end in builds)
Export-Package: app.inf

And the result is each bundle using a different build of app.bundle (which is leading to linkage exceptions). Thank you!

[kierann]

I tried:

Bundle A: Import-Package: app.inf;version="1.0.0"

but am just getting

An Import-Package could not be resolved. Caused by missing constraint in bundle <bundle.a_1.0.0.CI00178>
constraint: <Import-Package: app.inf; version="1.0.0">

[kierann]

I've whipped up a small example to help explain what I mean. Included are the project source code, a couple builds of each project, a plan file, and the dm server output of an instance when the error occurred.

[Glyn Normington]

It seems that the problem is caused because bundle.a uses Import-Package to obtain app.inf but bundle.b uses Import-Bundle of app.bundle to obtain app.inf.

Import-Bundle selects a bundle version as follows. If the imported bundle has already been installed, it selects the one with the lowest bundle id. If the imported bundle has not already been installed, it selects the one from the repository with the highest bundle version.

Import-Package behaviour is rather different. Again installed bundles are preferred. If no installed bundle exports the package, dm Server auto-provisions all exporters from the repository chain. These bundles are installed (in a side state but ultimately into the OSGi framework) in repository chain order but in an essentially random order within a given repository.

So I think what you are seeing is due to bundle.b importing app.inf from app.bundle v1.0.0.CI0010 and bundle.a importing app.inf from a lower version of app.bundle. A version of the app.inf.Data class is "leaking" through bundle.a into bundle.b which loads a different version of app.inf.Data and this results in the loader constraint violation.

I think you would avoid this and get more predictable results by using Import-Bundle of app.bundle in bundle.a.

However, you should also be able to fix the problem by adding a uses constraint to bundle.a. This will force the resolver produce a consistent class space that avoids the loader constraint violation. You need to add ';uses:="app.inf"' to the package export of bundle.a.service.

Did you use bundlor to generate the manifests? It should generate the correct uses constraint when it analyses the code of bundle.a.service. I strongly recommend using bundlor as it is complicated and error-prone to do the necessary analysis by hand.