New uses of the OSGi plug-in model
August 15th, 2006 by
Robert Enyedi in
Java, General
I grew accustomed to the OSGi plugin model having developed some Eclipse plugins and RCP applications. I found it reasonably simple and useful because it allows Java code isolation and management at a higher level (groups of packages). I think that these plugins are the closest to what component based software development should be.
In the OSGi plugin model there is no global classpath. A plugin has its own classpath or can inherit partially or totally the classpaths of other plugins. With this the so called “JAR hell” with multiple JAR versions on the same classpath is actually avoided.
Others seem to also find this plugin model useful. Recently I’ve heard of several usages of the OSGi plugin model outside of the Eclipse platform:
- in the eRCP project which promises plugin based mobile software development – some elements of this can be achieved even on J2ME: http://www-128.ibm.com/developerworks/wireless/library/wi-osgi/
- componentization of IBM WebSphere 6.1 with OSGi (http://www.eclipsezone.com/eclipse/forums/m92036274.html) with hints on the componentization of the Apache Geronimo project
- the 5 series BMW uses the OSGi specifications as the base technology for its high-end infotainment platform (http://www.hometoys.com/htinews/aug04/interviews/osgi/osgi.htm)
- JSR 291: Dynamic Component Support for JavaTM SE will also use OSGi. This way, among others, the ever growing rt.jar could be easily split into more manageable entities.
This link is a good start for getting to know the OSGi plugin model and how it integrates into the Eclipse platform: http://www-128.ibm.com/developerworks/opensource/library/os-ecl-osgi/.
The Wikipedia article on OSGi is also accurate: http://en.wikipedia.org/wiki/OSGi
August 15th, 2006 at 11:30 pm
I still think the model is not perfect. Think of the situations where you need to make a library publicly available to several plugins. The only way to do it and not duplicate it for all plugins is to create a new plugin which includes the library and make all other plugins dependent on your newly created plugin.
Since this has become something like a “standard” solution, why the Eclipse team doesn’t “standardize” it somehow, making this transparent to you (I can already think of several solutions).
August 16th, 2006 at 10:21 am
From the packaging point of view the OSGi plugin model is an evolution of the old JAR file format. An OSGi plugin can be packaged completely into a JAR file. In fact an existing JAR file could be easily transformed into a OSGi library plugin by adding plugin related information into the META-INF/MANIFEST.MF file. Thus the third party library libraries could easily be shipped as OSGi JARs which are usable as normal JARs.
This trend will start probably when JSR 291 will get into the JDK. Until than this operation has to be done manually, granted. But still, by doing this you avoid the problem of multiple JAR versions by elliminating the global CLASSPATH. And I also see this as a superior CLASSPATH management solution.