I’d like to shed a little bit of light on one of the tools we use in the Cortex maven build to make life working with OSGi just a little bit easier.
If you’ve had any exposure to Cortex, you may be aware that it’s built upon the OSGi framework, and if you’ve done any development on Cortex resource servers, you’ve probably noticed that you don’t have to spend all that much time writing or tweaking your bundle’s MANIFEST.MF. Contrast this with the development experience for CM Client, under either the current Tycho build model or the former ant build model. In these contexts, if you introduced a dependency on another package or bundle, you needed to make sure to add some instructions to the MANIFEST.MF of the bundle which consumes that dependency in order to ensure that OSGi wires things together correctly. These instructions can be tricky to get right when written manually.
Under Cortex, a different approach is used. The Cortex build employs a tool called the maven-bundle-plugin which analyzes the jar file produced by a bundle project to determine which packages, if any, the project depends on. Unless instructed otherwise, it will automatically add the packages that it discovered to the Import-Package header in the MANIFEST.MF. No manual intervention is required.
The maven-bundle-plugin is smart enough to inspect class files to determine what packages they reference. It also inspects Spring and Blueprint XML files, as well as the manifests of OSGi bundles that your project depends on in the event that you are embedding those jars directly instead your bundle. Under the hood, the plugin is actually relying on another tool, called bnd to do much of the work.
This automatic analysis of your projects is actually pretty good. Most of the time you don’t even need to think about the manifest, but sometimes the maven-bundle-plugin gets it wrong, and needs some additional hints. For example, while it can detect the class attribute of an XML bean definition, and knows to import the package of the class, it doesn’t understand the component-scan tag, eg.
<context:component-scan base-package="com.elasticpath.rest" scope-resolver="org.springframework.context.annotation.Jsr330ScopeMetadataResolver”/>
The maven-bundle-plugin will neglect to add an Import-Package for org.springframework.context.annotation, and your bundle will fail to start up.
We get around this by adding the following to the maven-bundle-plugin’s configuration in Maven:
<Import-Package>
org.springframework.context.annotation,
*
</Import-Package>
The first line of this instruction tells the maven-bundle-plugin to import the ‘org.springframework.context.annotation’ package regardless of what its analysis says, while the final line with the asterisk instructs it to add “everything else” that it finds.
There are lots of ways to tweak the instructions, but the maven-bundle-plugin docs and/or the bnd docs should be able to steer you in the right direction. The tools are complementary, as the maven-bundle-plugin layers on a bunch of maven capability onto the raw bnd tool, so sometimes there is a way to configure the plugin the way you need, but other times you may need to drop down into the underlying tool to get the job done.
I hope this helps make some of the magic which helps you write less code slightly less magical.
