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.

[kierann]

Thank you very much! Using Import-Bundle for everything would certainly be a preference. The discrepancy arose because Import-Bundle didn't work on bundles that were located in the usr repository of dm Server 1.x, but Import-Bundle is very handy, so only bundles that would not be deployed in the pickup directory used Import-Package.

I did get it working last night by adding proper versions to the Export-Package entries in all our bundles (I'm not sure why that is working now though...). But, from what you said, I think it might be worthwhile to go back and switch to using Import-Bundle instead of Import-Package where I can.

[Glyn Normington]

Ok, but please don't overlook the fact that you have a bug because of the missing uses constraint. This could result in issues later. I strongly recommend re-generating your manifests using bundlor when you have a chance.

[kierann]

Thank you very much. Is there a way to have bundlor not automatically include exported packages without maintaining a template.mf file?

[Glyn Normington]

Is there a way to have bundlor not automatically include exported packages without maintaining a template.mf file?

I'm not aware of any way to do that. But please check the bundlor documentation and discuss this requirement on the dm Server tooling forum.