What is a reasonable OSGi development workflow?

Question

I'm using OSGi for my latest project at work, and it's pretty beautiful as far as modularity and functionality.

But I'm not happy with the development workflow. Eventually, I plan to have 30-50 separate bundles, arranged in a dependency graph - supposedly, this is what OSGi is designed for. But I can't figure out a clean way to manage dependencies at compile time.

Example: You have bundles A and B. B depends on packages defined in A. Each bundle is developed as a separate Java project.

In order to compile B, A has to be on the javac classpath.

Do you:

1. Reference the file system location of project A in B's build script?
2. Build A and throw the jar into B's lib directory?
3. Rely on Eclipse's "referenced projects" feature and always use Eclipse's classpath to build (ugh)
4. Use a common "lib" directory for all projects and dump the bundle jars there after compilation?
5. Set up a bundle repository, parse the manifest from the build script and pull down the required bundles from the repository?

No. 5 sounds the cleanest, but also like a lot of overhead.

Answer 1

My company has 100+ bundle projects and we use Eclipse to manage the dependencies. However, I don't recommend the "Required Plugins" approach to managing the dependencies. Your best bet is to create Plugin Projects. Export just the packages from each project that you want to be visible. Then on the import side do the following:

Open the Manifest editor

Goto the dependencies tab In the bottom left is a section called "Automated Management of Dependencies"

Add any plugins that the current plugin depends on there

Once you have code written, you can click the "add dependencies" link on that tab to auto-compute the imported packages.

If you run from Eclipse, this gets done automatically for you when you execute.

The benefits of this approach is that your built bundles are only using OSGi defined package import/export mechanism, as opposed to something from Eclipse.

If you want to learn more, I'd recommend going to this site and ordering the book. It's excellent.

http://equinoxosgi.org/

Answer 2

Well, do what you should have a long time before, separate implementation and API ... ok, this is not always that easy on existing systems but that model has a huge bang for your buck. Once your API is in a separate (much more stable) bundle/jar you can compile the clients and implementations against that bundle/jar.

One of the key qualities of a successful bundle is that it makes as little assumptions about the outside world as possible. This implies you do not have to compile against the bundles you run against in runtime, I have a preference to try hard to not do that. You should only compile against the bundles minimum set of dependencies. If assumptions are made they are explicit as imported packages and the use of services. Well designed OSGi systems attempt to use services for all inter-bundle communications. Not only does this model get rid of class loading issues it also makes your build setup more decoupled.

Unfortunately most code is written as libraries that have a rather wide interface because they hand code lots of the functionality that services provide out of the box like Factories and Listeners. This code has a tight relationship between implementation and API so you have to have the same on the class path during compile and in OSGi. One solution to this problem is to include this kind of code inside the bundle using it (but make sure no objects of this library leak to other bundles). A bit of extra memory consumption but it saves you from some headaches.

So with OSGi, try to create systems relying on services and compile against their service API, not an implementation bundle.