Bundle.update: the Current State of OSGi
As well as the release earlier this year of Equinox 3.5, which implemented the draft OSGi specifications, Apache Felix 2.0 has recently been released with OSGi 4.2 support. In addition, Knopflerfish 3.0 beta was released yesterday which implements the 4.2 core, except for the framework launcher is currently a work in progress.
Building upon the core frameworks is Apache Karaf 1.0, released two weeks ago. This aims to be an engine-agnostic distribution of an OSGi framework with several useful bundles already packaged, such as Blueprint, provisioning, logging and remote access (via SSH). For those new to OSGi, this might be a good starting point to use, since it is an all-in-one package, much like Linux distributions build upon the standard Linux kernel to provide additional features/management.
SpringSource (now owned by VMware), has recently released dm Server 2.0M5, including the diminutive dm Kernel, which as well as providing the OSGi reference implementation for the Blueprint service (covered earlier at InfoQ), also utilises a feature called nested frameworks. This was a proposed addition for OSGi 4.2 which was left out to gather more experience for a future release, but allows an OSGi framework to create an internal framework (or region in dm Server terminology) for a specific application. This allows multiple applications to be installed and be partitioned from other frameworks on the system. Experience gained with this will no doubt go into the planning for the next OSGi release.
Jetty has recently released 7.0 (covered previously by InfoQ) and acts as both a standalone Java web engine as well as being embedable in other applications (both OSGi and traditional Java). Oracle have also announced the WebLogic roadmap which includes the on-going OSGi-based microService Architecture. Lastly, the Sun developed GlassFish server has GlassFish V3 Preview, based on OSGi, available to download.
The OSGi Enterprise Expert Group is working towards defining a set of OSGi services (for example, resolving JNDI and web Servlet bindings) and has already worked towards the OSGi remote services, which became part of the 4.2 specification. The expert group aims to provide a release early next year, but already it seems that every major application server is basing their runtimes on OSGi.
Running OSGi systems is simple enough, but build remains challenging. Whereas solutions like Ant typically deal with a flat classpath, as well as complete visibility of public packages, the OSGi runtime provides a more modular classpath (both at runtime and therefore implicitly at compile time as well). Existing build solutions like Eclipse's PDE build work well for the specific use cases (e.g. building Eclipse plugins) but tend not to work for IDE agnostic or headless builds in custom layouts. There has been progress in other build engines, such as Apache Sigil, which is based on Any/Ivy and aims to support not only Eclipse but also NetBeans OSGi development as well. Although still in incubation, it has recently become self-building and a full release is planned for later in the year.
Pax Construct has become an indispensible way of building Maven-based builds, using a combination of the bnd tool, which is also used by the Felix maven bnd plugin. There's even talk of making Eclipse's artefacts from a Maven repository which would help those wishing to create Maven-based OSGi builds and consuming Eclipse based bundles. However, it's likely that this will be available for a small subset of projects initially which will demonstrate the benefit/need of such a system.
Eclipse, meanwhile, is focussing on build with another
[A-Z][0-9] project, this time called B3. This won't substantially change the way Eclipse projects are built; rather, it will aim to combine the current PDE build along with other build/deployment systems like Buckminster and the Hudson based build system.
Whilst NetBeans still remains slightly removed from OSGi, builds of netisgo (which provide OSGi support for NetBeans) are still ongoing. On the other hand, IntelliJ 9.0 Preview has recently been released, which includes OSGi support in both the community and ultimate editions (although it's a separate plugin download for the community edition).
Eclipse 3.6M2 has been available for a few weeks, and provides a milestone of the Eclipse platform's next release. The Equinox support also includes OSGi EventAdmin, which is being used more heavily in the ongoing development of asynchronous support in the OSGi platform. (Equinox previously supplied EventAdmin as a separate downloadable bundle, which meant that few ever used it; by incorporating it into the RCP it will be available by default in more locations and thus used more in the future.) Equinox 3.6M2 also brings the ability to do classloader-weaving in the bundles, by using AspectJ to inject code at bundle load time. In addition, the Equinox console has been made multi-session, allowing multiple users to concurrently connect to a remote instance.
JSConstants objects. There's a New and noteworthy for the E4 1.0M1 release.
The conference season is looking up over the next six months, with OSGi being particularly well represented across several conferences. The first is next week's SpringOne America, which will have the results of the Burton Group 2nd Annual OSGi Survey (please take a moment to fill it in before 19th Oct if you haven't already). Following that is EclipseCon Summit Europe at the end of the month, and then QCon SF next month. Next year will see OSGi DevCon London 2010 in January followed by QCon London at the start of March, and EclipseCon 2010 in California.
The global OSGi User Groups continue to go well; the recent OSGi in Anger by Tara Simpson of Instil Software held at Paremus discussed the experience of a telecom system using OSGi in order to remotely manage and provision services on nodes. Given the conversation that followed on into the bar (sponsored by Luminis) it seemed that it was well received. The presentation and video, recorded by SkillsMatter, are available at the meeting page. A recurring theme of these kind of projects is that the move from a seemingly modular system to OSGi helps identify where packages have leaked; Jetty discovered the same when moving to Eclipse. Furthermore, once these systems have moved to OSGi it's difficult to see how to go back to building complex systems without using OSGi.
What of the Simple Module System, which aimed to provide a common ground between OSGi and Jigsaw? Although initially promising, there is a difference of opinions as to whether the runtime space should be a flat classpath (like Java is at the moment) or a nested classpath (like OSGi and the compile path). A future expert group call might help, but as yet does not appear to have happened. Neil Bartlett will talk about this state of affairs and more in London in two weeks time, in Modularity: a view from the gallery.
InfoQ is running a series on Java Modularity; the next in the series will be posted next week.
Re: Apache Aries isn't news?