Aehso’s Output

Eclipse OSGI core CLI

With the release Eclipse 3.0, the Eclipse platform migrated the core runtime onto a new OSGI R3 implementation as the basis for its whole plugin framework. The OSGI implementation provides all the low level bootstrapping, plugin classpath management, dependency resolution, APIs exposure control and and whole host of other (currently underutilized) facilities. Eclipse users havn’t noticed the change since it’s all under the hood but Eclipse plugin developers have noticed as the plugin framework is now a little more powerful and metadata can now migrate from the trusty plugin.xml descriptor into an archive’s MANIFEST.MF file, as prescribed by the OSGI specification.

Recently, the OSGI implementation has been promoted to a sub-project of the Platform project and is now publically known as the Equinox project. Effectively they have seperated the OSGI implementation from the rest of the Eclipse platform and now distribute the OSGI framework as one 700k jar. That’s a lot of very useful framework packaged into a very small archive. What got me more interested is that they added a command line interface onto their OSGI framework. Launching it is as simple as:

C:\eclipse\plugins>java -jar org.eclipse.osgi_3.1.0.jar -console

That gives you a little ‘osgi’ prompt:

osgi>

Here’s a hint - enter ‘?’ for help - I’ll not paste it all in here but suffice to say that you can do a lot from that little prompt. There’s lots more at the Equinox quickstart page.

Now here’s where it gets interesting. Java has needed something like this for a very long time and the Java Community Process are starting work on a Java Module System(JSR 277) specification. The initial description of that JSR pointed out that OSGI R3 had some limitations that rendered it unsuitable for consideration. But now Eclipse now supports OSGI R4 - I wonder does it resolve those issues?

I expect to see OSGI play a larger and larger role in Java library/application packaging and distribution in the future. However, OSGI really only provides benifits if the packaged code is modular and easily pluggable. Monolithic messes that cannot be decomposed into multiple bundles will not gain as much benifit.

No comments yet.

Leave a comment