Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2574 posts at DZone. You can read more from them at their website. View Full User Profile

Bundlor 1.0 RC1 - Managing OSGi Bundle Manifests

12.23.2009
| 10822 views |
  • submit to reddit
For developers who want to manage their own bundle manifests, but need a little help to automating the details, like specifying package versions across a range of imports, the Bundlor tool is now available and is feature-complete.  Bundlor, a SpringSource project, can also help developers who want to generate manifests based on the content of their project and the dependencies specified in their build files.  The tool works with libraries that don't have the necessary OSGi metadata to enable their use in an OSGi Service Platform.  Bundlor automates dependency detection and the detection of OSGi manifest directives for JARs after their creation.

Spring has been using Bundlor internally for some time to manage the bundles published to the SpringSource Enterprise Bundle Repository.  Bundlor takes a JAR as input and a template consisting of a superset of the standard OSGi manifest headers, and then it analyzes the source code and support files in the JAR, applies the template to the results, and generates an OSGi-compliant manifest.  In the analysis stage, Bundlor looks for class references and class names in Java classes and certain well-known file types.  Because Bundlor scans for any Java class in the artifact created by the underlying build system, it can see changes made by the custom build processes (i.e. weaving with AspectJ or jarjaring), as long as the changes are in the artifact.  Bundlor detects the Java type references in a Java class and adds manifest requirements for them.

OSGi Profiles
Managing and transforming a multitude of bundles in the SpringSource Enterprise Bundle Repository can become difficult when developers have to remember which packages are boot delegated (exported from the system bundle) and which packages are from other bundles in a system.  In most cases, developers don't want to import boot delegated packages into their own application.  Instead, it's better to import system bundle packages at version 0 and define custom imports for the rest of the bundles.  Keeping track of which packages are in each of these categories can be difficult and cause problems.  Defining template entries for the categories in a manifest template can be time-consuming and tedious.

Bundlor can take an OSGi profile as input and automatically add template entries for boot delegated packages and system bundles. The import entries ignore boot-delegated packages and set the version of system bundles to version="0". This feature is available in all of the Bundlor front ends, including command-line, ANT, and Maven.  Another major feature in Bundlor is its support for the Blueprint spec.  Bundlor can find OSGi Blueprint Service files, scan them for class and interface names, and add packages for those types to the OSGi manifest.

An OSGi profile defines the packages that an OSGI runtime (the Spring dm Server is one example) exports from the system bundle and the packages delegated to the boot class loader.  OSGI profiles aren't actual files.  They are two properties that are well-known to an OSGi runtime.  They are:
  • The org.osgi.framework.system.packages property, which defines the packages exported from the system bundle.
  • The org.osgi.framework.bootdelegation property, which defines the packages that are boot delegated.

These properties become a file when you pass these properties to Bundlor.

The first step in using OSGI profiles with Bundlor is creating a file that contains textual representation of the two properties (listed above) that make up an OSGI profile.  Users typically start with the OSGI profile of their particular OSGI runtime, and then customize it to fit their development environment.  Bundlor works with many different OSGi runtimes, including Spring dm and Eclipse's Equinox.  The snippet below shows a partial OSGI profile for dm Server.  Only a few packages are shown, but the example shows the format for creating OSGI profile file:
org.osgi.framework.system.packages = \
javax.accessibility,\
javax.activation,\
javax.activation;version="1.1.0",\
javax.activity,\
javax.annotation,\
...

org.osgi.framework.bootdelegation = \
com_cenqua_clover,\
com.cenqua.*,\
com.yourkit.*,\
...

After creating the OSGI profile file, the method of passing it to Bundlor depends on the front end that's being used to generate a manifest.

BundlorEclipse
Bundlor provides an Eclipse integration (BundlorEclipse) that can be used on any Eclipse Java project that has the SpringSource OSGi Bundle project nature. It doesn't require using the Bundle Classpath Container.  Within Eclipse, Bundlor uses source code analysis based on Abstract Syntax Trees created with Eclipse JDT to process Java source files. This means that BundlorEclipse can generate manifest files without an existing project classpath.  It can also generate manifest files from non-compiling, partial Java code.  Bundlor also supports Spring configuration files, Hibernate, and JPA mapping files.  All of these resources can be processed within Eclipse.  BundlorEclipse is available with the Spring dm Server Tools 1.1.3, which are licensed under the Eclipse Public License 1.0.



See the Bundler user guide and a getting started tutorial for more guidance on how to use Bundler.