The work to produce the enterprise edition of the OSGi specifications is roughly divided between these two groups, based on whether a particular work item changes the core platform framework itself (CPEG), or to extends the core platform with new features (EEG).
The goal is to complete work on R4.2 in time to deliver compliant software in the Eclipse Ganymede release, scheduled for June 2009. This is because the Eclipse platform, Equinox, is currently the reference implementation of OSGi. However, we have had good participation in the meetings from the other platform providers, including Apache Felix, Prosyst, and sometimes Makewave. It is looking tight, but do-able. And we made some good progress Wed-Thurs last week.
Since I’m EEG co-chair I’ll concentrate on that from here on. During Thursday’s meeting we pretty much closed out the major design documents: Blueprint Component Model (Spring-“inspired”) and Distributed OSGi. The Blueprint, aka Spring/DM (see discussion here) and is nearly complete, just working on the final collection of bugs, most of which have been submitted by Rick McGuire of the Apache Geronimo team, who’s developing the conformance test suite (TCK). SpringSource is providing the reference implementation, which has been available for some time in the Spring-DM project.
Needless to say, the Spring mapping document, aka RFC 124 (see Adrian’s excellent summary for what it means) is probably the most important work item for the EEG.
Next is probably the Distributed OSGi document, aka RFC 119, which defines extensions for configuring OSGi services to communicate remotely using existing distributed software systems. The RI we recently demo’d for this is hosted at Apache CXF, and David Bosschaert recently posted a Spring-DM update for it. Tibco is working on the TCK, so we are in pretty good shape overall now.
During the afternoon, Yan presented LinkedIn’s view of OSGi, including information about their requirements for using it in their next-generation platform. Jan drew pictures on the whiteboard, and used bits of this slideshow. Their major interests are improving the modularity of their applications, and updating them more easily and dynamically. It’s great to have a user company participate in the meetings – we could actually use more and I hope more will consider joining.
After Yan’s presentation we focused on the Java EE mapping work, which has progressed intermittently throughout the past couple of years. It was always a goal of enterprise OSGi to include components of Java EE, but it was not always easy getting everyone to focus on the work and agree on a direction. At the Board meeting in June however, the Java EE work was identified as a priority for the release, and since then we we have been more focused on it and are starting to get somewhere, although significant work remains.
After discussing the topic with others, I believe the priorities are improving the support for Web applications, and for mapping JNDI, JPA, and JDBC. The design docs are in pretty good shape for JTA and JMX, so those are ok. It will be tight, but it looks like we have the right people assigned from Oracle, IBM, and SpringSource to make it happen. Maybe security is also needed…?
Of course, it’s easy for me to say the design docs are in pretty good shape now, and that several from CPEG and a few from EEG are ready to move into the formal specification phase, but Peter Kriens actually has to write the specs now, and we will have to see how he gets along…
ps on the drive back to the airport, I took a brief detour to Arles, and toured the old Roman town, including the collesium, which is still used, apparently for bullfights (not Christians and lions anymore..)