Building Source Features with the PDE Build

The PDE Build provides a pretty convenient way of automatically creating a source feature. The additional feature contains all source files and artefacts listed in the containing bundles’ build.properties files for a source build. There are only a few settings necessary.

Assume we have a feature com.foo.feature containing some bundles with binaries only.

First, we need to configure a source feature include for the feature. Simply add a line to the com.foo.feature feature’s feature.xml:
<includes id="com.foo.feature.source" />

The linked feature com.foo.feature.source does not exist yet, it will be created by the PDE Build later on.

To get the PDE Build actually creating the source feature, we have to edit the com.foo.feature features’s build.properties by adding another line to it:
generate.feature@com.foo.feature.source = com.foo.feature

The PDE Build will now build the linked source feature com.foo.feature.source including a bundle containing all sources of all binary bundles included in the com.foo.feature feature. Since Eclipse 3.4, we can tell the PDE Build to create an individual source bundle for each bundle by setting a PDE Build property individualSourceBundles to true.

Fragments vs. Buddy Classloading

Classloading is a serious issue when creating OSGi based applications. As each bundle is bound to it’s own classpath, sometimes the reflection mechanism will not work as expected. So, there are basicly two ways of solving the problem of extending a bundle’s classpath (when using Equinox…), either create a feature or use Buddy Classloading. But which solutions fits best for what problem?

Fragments

A fragment is an OSGi mechanism to allow a dynamic extension of a bundle at runtime. The fragment itself is not a true component as other bundles may not define a dependency on the fragment. It is used for different purposes such as testing, internationalisation or logging configuration. You can add system dependent code or configuration files to a generic implementation. The good thing is, that the extended code has no dependency on the fragment i.e. does not necessarily require the fragment for running (for example testing fragments).

How to
A fragment is structured as a common bundle. It may be created using a wizard (in Eclipse) or by adding a line to the manifest.mf of a common bundle defining the so called fragment host:
Fragment-Host: bundleSymbolic-Name
This advises the runtime to merge the fragment’s content with it’s host at runtime.

What’s good
Fragments are pure OSGi and provide the flexibility of extending a component dynamicly at runtime without breaking the component architecture. Some third party classpath requirements can be solved this way, for example providing a logging configuration.

What’s bad
Some third party classpath requirements cannot be matched using fragments.

Buddy Classloading

Buddy Cassloading is somewhat a hack (in my opinion), as it adds a bundle’s classpath to another’s – you could call it ‘reverse-dependency’. In OSGi terms, this is explicitly not wanted as a bundle should be treated as a component. But since many Java libraries got used to a single classloader environment, they still expect an exclusive access to any class of the application using reflection. So, in some situations, you can’t really avoid using Buddy Classloading in an Equinox environment.

How to
The manifest.mf of the bundle to be extended receives an additional line to define a Buddy Policy:
Eclipse-BuddyPolicy: registered
This defines the bundle to be aware of registered bundles which entend the classpath.

The manifest.mf of the bundle to extend receives two additional lines:
Eclipse-RegisterBuddy: bundleSymbolic-Name
Require-Bundle: bundleSymbolic-Name

This defines the bundle to extend the classpath of the listed bundles. Additionally, the registered Buddy Policy requires the extending bundle to have a dependency on the extended bundle.

What’s good
Buddy Classloading easily enables using common reliable libraries without any problems. Additionally, the extending bundle can still be treated as a ‘normal’ bundle, other bundles may have a dependency on the bundle and use the exported packages as provided.

What’s bad
Buddy Classloading is not ‘the OSGi way’ as it corrupts the idea of having a component based application with clearly separated bundles defining an interface and dependencies. Buddy Classloading is an answer to a technical problem and should not be used for application design.