Community
Participate
Working Groups
Build Identifier: The maven-bundle-plugin from Apache Felix auto-inserts an Import-Package: org.osgi.service.blueprint if it sees one using blueprint via OSGI-INF/blueprint/*.xml files. It does this because the spec supposedly encourages blueprint implementations to export this package: http://mail-archives.apache.org/mod_mbox/aries-user/201106.mbox/%3CBANLkTi=DH5hd9a95NDcUhZWXLMHDg7fJ0Q@mail.gmail.com%3E Gemini isn't alone. Here is a related bug in Aries: https://issues.apache.org/jira/browse/ARIES-670 Reproducible: Always Steps to Reproduce: Build a bundle using maven-bundle-plugin. Use some simple blueprint.xml configs. Run the bundle in Felix, but include the gemini 1.0.0-RC1 jars as the blueprint implementation. You get this error on launch: Unable to resolve 10.0: missing requirement [10.0] package; (&(package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
The relevant section of the blueprint specification is 121.13.5 Type Compatibility. It states that: To mitigate type incompatibility problems, a Blueprint extender must export the org.osgi.service.blueprint package. In the uses: directive, it should list any packages of classes that can be shared between the Blueprint extender and the Blueprint bundle. Blueprint bundles should import this package.
Any further thoughts on this? This bug makes it impossible for bundles to interoperable with Gemini and Aries. We have to build for one or the other and either include the mask out or keep int to spec.
Patch submitted: https://github.com/eclipse/gemini.blueprint/pull/1
(In reply to comment #3) > Patch submitted: > https://github.com/eclipse/gemini.blueprint/pull/1 Thanks but the package should be exported at version 1 and the marker class is unnecessary. I prefer to export the package from the extender bundle since systems which auto-install and start the extender bundle (which pre-req's the core bundle) are more likely to work than those which auto-install and start the core bundle. Also, this choice of exporter fits in a little better with the wording of the OSGi spec. "a Blueprint extender must export the org.osgi.service.blueprint package". I know that "Blueprint extender" does not necessarily equate to a single bundle, but it's more natural to export the package from the extender bundle. Fixed in commit b13ad3b69af13a39722881ceb76fbc47f72085e9. I added an export of org.osgi.service.blueprint at version 1 (equivalent to 1.0 or 1.0.0) to the extender bundle manifest template.
I tried this approach but found that the resulting jar did not actually export the package. Bundlor ignored my manifest template entry. Can you eyeball the jar's manifest to make sure it's there?
(In reply to comment #5) > I tried this approach but found that the resulting jar did not actually > export the package. Bundlor ignored my manifest template entry. Can you > eyeball the jar's manifest to make sure it's there? Yes, it's there. However, I realised overnight that I should have added a uses directive, so I'm just adding that and testing.
Extract of the extender manifest I just built: Export-Package: org.eclipse.gemini.blueprint.extender;version="2.0.0.B UILD-SNAPSHOT";uses:="org.eclipse.gemini.blueprint.context,org.osgi.f ramework,org.springframework.beans,org.springframework.beans.factory. config",org.eclipse.gemini.blueprint.extender.event;version="2.0.0.BU ILD-SNAPSHOT";uses:="org.eclipse.gemini.blueprint.context.event,org.e clipse.gemini.blueprint.service.importer.event,org.osgi.framework,org .springframework.context",org.eclipse.gemini.blueprint.extender.suppo rt;version="2.0.0.BUILD-SNAPSHOT";uses:="org.eclipse.gemini.blueprint .context,org.eclipse.gemini.blueprint.extender,org.eclipse.gemini.blu eprint.extender.support.scanning,org.osgi.framework,org.springframewo rk.beans.factory",org.eclipse.gemini.blueprint.extender.support.scann ing;version="2.0.0.BUILD-SNAPSHOT";uses:="org.osgi.framework",org.osg i.service.blueprint;version="1";uses:="org.osgi.service.blueprint.con tainer,org.osgi.service.blueprint.reflect"
