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