• The OSGi and Gravity Service Binder Tutorial on the Oscar site starts with the simplest bundle and works up. A good starting point, even though the service binder is Oscar-specific (the concept is still useful, however, and explained from first principles).
• The Knopflerfish tutorial, which again starts from the very basics. Some of the content is specific to Knopflerfish, but the OSGi basics are also covered in a hands-on fashion.
• The aQute OSGi Tutorial, which is a detailed presentation with accompanying source code. Uses Eclipse/Equinox as a basis to develop some simple OSGi-based applications. A good next step once you know how to make the simplest bundles.

These links should help you get over the initial hump with OSGi.

It promises to be a very interesting trip, not least for the fact that both Jason and I use IDEA for our development. I have not used Eclipse for quite some time, and last time Jason tried, it killed his mouse. But just maybe it is time to give Eclipse another try? With its support for developing plugins, it will certainly help with developing extensions for Pulse.

If anyone is interested in catching up with us while we are state side, send us an email. We are looking forward to talking to Pulse users and a little madness readers alike.

So what is OSGi? If you head to the official website for the answer, you could be forgiven for thinking you had stumbled on a game of buzzword bingo. The terms “universal middleware”, “service oriented” and “component based” show up in the first couple of sentences! Putting marketing-speak aside, however, OSGi turns out to be a mature standard for dynamic modules (read: plugins) for Java. Despite the buzzwords, it is also pleasantly simple at its core (plugins are just Jar files with metadata in the manifest). If you’re looking to create a plugin-based application, or to add a plugin system to your existing application, then you should look into OSGi.

In our case, we are adding a plugin system to the next major version of Pulse. We have decided to go with OSGi for a variety of reasons:

• A robust standard for the basic requirements of a plugin system: such as plugin metadata, dependencies, classloading, service management, dynamic loading/unloading and so on. Why reinvent a less complete system?
• A simple core: OSGi plugins (known as bundles) are just plain old Jar files with some metadata. This simplicity will make our life much easier.
• Existing open source implementations: we have chosen the Eclipse foundation’s Equinox implementation, but there are others such as Felix, Knopflerfish and Oscar.
• Eclipse tooling support: as Eclipse uses OSGi under the covers, the Eclipse Plugin Development Environment has tool support for creating and managing OSGi bundles. One of our goals is to make the lives of plugin authors as simple as possible: tool support helps achieve this.

Of course, it is not all good all of the time. There are some challenges we face along the way:

• Lack of documentation: it is seriously difficult to find good documentation about OSGi and the implementations, apart from the standard itself (which happily is reasonably readable). The saving grace is having the Equinox code and a helpful development community.
• Embedding Equinox: the Equinox framework, as part of the Eclipse project, has a certain bias towards being used as part of the larger Eclipse platform (and Rich Client Platform). This is changing over time, but we are finding some interesting challenges embedding Equinox in Pulse.
• Impedence mismatches between Pulse and OSGi: at times the default OSGi behaviour is at odds with how we would like plugins to act in Pulse. For example, OSGi mandates that the state of plugins is persisted by the framework, whereas we want Pulse itself to have control over their state.

As we continue the implementation of a plugin system for Pulse, I’ll post more about the particular things we learn along the way. Hopefully this information will help fill the documentation black hole, particularly in a new area for Equinox: embedding in a standalone application.