Hi, I work with OSGi all the time so this sounds very appealing to me.
Firstly, here's a primer that I wrote - purely conceptual for those who know Java and have heard OSGi, but don't really know what it is: http://java.dzone.com/articles/osgi-primer So, OSGi is a specification for modular and dynamic Java. There is a core specification, which is the minimum requirement for any framework and then there is the service compendium which includes a whole load of useful services that are optionally implemented by an implementation. There are a number of things in the service compendium that probably aren't appropriate, e.g. HttpService. All the specifications can be found here: http://www.osgi.org/Specifications/HomePage Pivot doesn't need to use/provide any of the optional services and of course we can create our own services that application developers can then use themselves. In order to use OSGi, we would have to find or build an implementation. There are quite a few implementations out there already, so we would need a very strong reason to re-implement it from the ground up. The obvious first port of call for this project is Apache Felix since it is an Apache project: http://felix.apache.org/ But I strongly recommend that people play around with these as well: Equinox (the implementation Eclipse is built on) : http://www.eclipse.org/equinox/ Knoplerfish: http://www.knopflerfish.org/ I know that Equinox has implementations of all the optional services, but I couldn't speak for Felix or Knoplerfish. There are probably others, but these are the three 'leaders' as far as I am concerned. The pure OSGi approach is the service registry in which services are registered and consumed by the bundle Activators. The whiteboard model recommends that bundles register services for consumption rather than trying to lookup services, but it really depends on what you're trying to do, of course. Eclipse has taken the core OSGi concept and, perfectly legitimately, added an extension point registry. An Eclipse plugin usually has a plugin.xml in it and this declares extension points and defines which extensions are provided by the plugin. The registry watches bundles being installed and reads the plugin.xml from the bundle if it is available. IMHO, The Extensions and Extension Points approach is more suitable to building UIs based applications than using the service registry and this is exactly how the majority of the Eclipse IDE hangs together. One problem that immediately springs to mind is that one of the core things that OSGi provides is a data area, somewhere that bundles can read and write files. This maybe a problem for Pivot since it will often be running in a sandbox with strict security policies. As such, it maybe that we need to modify whichever framework we base our work on in some way, but then we potentially don't have an OSGi compliant container. I'll have to re-read the spec to work out what we can get away with. Also, while OSGi is quite lightweight for building command line, desktop or server apps (e.g. the minimum requirement bundle for Equinox ways in at 994k) to me that still feels a little heavy for the starting position for an applet based application. Then again, perhaps Felix or Knoplerfish have smaller footprints, that is very possible. Hope that helps. Please feel free to shout out questions. Cheers, Chris 2009/3/25 Greg Brown <[email protected]> > Hi all, > > Now that we're pretty much done with version 1.1, we're starting to think > about features for the next release of Pivot, version 1.2. One topic that > has been discussed is OSGi support. We understand OSGi from a high level and > think that support for OSGi-style modules or bundles would be a valuable > addition to Pivot. However, we don't know enough about it to know if this is > something that we'd need to build from scratch or if there are existing Java > libraries that we could take advantage of. > > If anyone has relevant experience and would care to share your insight, we > would appreciate it. > > Thanks, > Greg > > >
