How can I manage OSGi build dependencies?

Question

We've embedded an OSGi runtime (Equinox) into out custom client-server application to facilitate plugin development and so far things are going great. We've been using Eclipse to build plugins due to the built-in manifest editor, dependency management, and export wizard. Using Eclipse to manager builds isn't very conducive to continuous integration via Hudson.

We have OSGi bundles which depend on other OSGi bundles. I'd really hate to hardcode build order in a custom ANT build. We've done this is the past and it's pretty horrible. Is there any build tool that can EASILY manage OSGi dependencies, if not automatically resolve them? Are there any DECENT examples of how to this?

CLARIFICATION:

The generated build scripts are only usable via Eclipse. They require manually running pieces of Eclipse. We've also got some standard targets which the Eclipse build won't have, and I don't want to modify the generated file since I may regenerate (I know I can do includes, but I want to avoid the Eclipse gen file all together)

Here is my project layout:

/
-PluginA
-PluginB
-PluginC
.
.
.

In using the Eclipse PDE, each plugin has a Manifest, but no build.xml as the PDE does that for me. Hard to automate a gui driven process w/ Hudson. I'd like to setup my own build.xml to build each, BUT there are dependencies and build order issues. These issues are driven by the Manifest files (which describe OSGi imports). For example, PluginC depends on PluginB which depends on PluginA. They must be built in the correct order. I realize that I can manually control the build order, I'm looking for a tool to help automate the build order dependency management.

Answer 1

Could you explain the shortcoming you encountered using the build.xml files generated by Eclipse with Hudson? Maybe there is still something to explore in that direction.

Answer 2

We use Buckminster. It's a build and assembly framework, which takes care of the resolution of dependencies, the fetching from various repositories, building and packaging of the product.

It's an Eclipse Tools project. It integrates well with PDE.

This means that all the meta-data we use to build the RCP is useful to Buckminster to resolve and build. For example, feature.xml and the Require-Bundle header in the Manifest.MF, .product.

We haven't got any build scripts in each bundle now; we now have a single build per product. Buckminster takes care walking the dependency graph.

It took a little bit of effort to get our existing cruise-control/ant system working with it, though they (the Buckminster team) have started using Hudson to host the project itself. I believe that their build setup is also available for download.

We're really impressed with it, despite it's relative infancy.

We also looked into Pax-Construct but we didn't want to use Maven.

We're also currently looking at Spring DM testing framework to augment the unit testing effort.

Answer 3

Maven2 all the way; has an Eclipse plugin called m2eclipse to help with managing it, solves exactly the dependency problem and then some. Has a free online book as documentation.

Specifically look at multi-module projects for bundling many components together and have Maven work out the build order and dependencies.

There is also a chapter on the Eclipse integration.

And that is just Eclipse and Maven, next you get some cool goodies for OSGi:

• The Apache Felix BND Maven plugin will auto-generate your manifests or at the very least help you
• The PAX OPS4J project and their Maven plugins can be a great help in bootstrapping projects, providing launchers, etc

And just fundamentally, the Maven module model fits perfectly with OSGi's bundle model. We've been building and managing multiple products with hundreds of bundles using Maven for more than 3 years now and it's great.

Answer 4

Can you please elaborate where the problem occurs? You mention OSGi bundle dependencies. Is this during runtime? Or during compile-time? In the first case you should consider Declarative Services (see OSGi Spec).

Answer 5

We use Hudson combined with PluginBuilder to build our Eclipse-based OSGi bundles/plugins. This builds upon Eclipse's standard PDE process for building plugins. This means using Eclipse as the compiler.

Answer 6

Seconding Maven2. Look into the Tycho plugins for building - they use Eclipse's JDT compiler so it implements all of the OSGi rules at compile-time, the same way Eclipse does at runtime.

Alternatively, the Apache Felix BND plugins also seem popular. I prefer Tycho because it more closely seems to unify the Maven and Eclipse development environments.

Answer 7

Closing out some old questions...

Our setup was not conducive to maven due to lack of network connectivity and timing. I know there are offline maven setups, but it was all too much given the time. Hopefully we'll get to use a proper setup when we've got time to reorganize the build process.

The solution involved Ant, BND, and some custom ant tasks. The various bundle dependencies are manually managed. We were already using Ant; BND and custom tasks tied it all together. The custom tasks just made sure our bnd/eclipse projects were in sync.

Answer 8

PDE Headless build. It's well documented by Eclipse. If you're building Eclipse plugins, and you want to do it via command line, The Eclipse PDE headless build is THE way to go.