Why doesn't bytecode modification work with OSG i? The problem is that code that's
instrumented to collect coverage data will have extra dependencies. In a non- OSG i envi-
ronment, the classpath is flat, so it's sufficient to have the coverage library on the class-
path. In an OSG i environment, with its structured classpath and limited class visibility,
a bundle must explicitly import any new dependencies added at runtime.
OSGi support for load-time weaving
Version 4.3 of the OSGi specification includes new support for load-time bytecode
weaving of classes. Although at the time of writing no coverage tools exploit this
capability, expect future tools to take advantage of this extremely useful facility.
If you want to collect coverage data for your enterprise OSG i application (you do),
there are two options. A few tools have been specifically designed to support OSG i cov-
erage collection. Alternatively, you can carry on using your favorite tools by doing cre-
ative classpath manipulation.
The most well-known coverage tool with built-in OSG i support is EclEmma. But as
the name suggests, EclEmma only supports Eclipse Equinox.
Getting coverage tools onto the classpath
If you're fond of another tool, like Cobertura, or using Felix as your OSG i framework,
there are ways to make non- OSG i-aware tools work. One option is to explicitly import
the coverage library packages in the manifests of your instrumented bundles. You'll
either need to produce two versions of the bundle, one for testing and one for pro-
duction, or make the coverage imports optional. Another option, which is less disrup-
tive to your manifests, is to add the coverage classes to your boot classpath and use
boot delegation to ensure all bundles can see them.
T ycho test
Figure 8.3 A range of tools for building, developing, and testing OSGi applications is available. Many
of the tools build on or integrate with other tools, or even several other tools.