R4.2: Next release of OSGi, and what's next

Alex Blewitt posted a great write up to InfoQ of Peter Kriens' recent presentation on the next release of OSGi, which is called R4.2.

This release started in September 2006 with the OSGi Enterprise Workshop. When I volunteered to co-chair the EEG in December I remember being told it would take about two years to get the release out. Pretty close I guess...

The presentation is kind of long (112 minutes), but well worth watching if you're interested in OSGi, or in hearing Peter's view of what's gone wrong with the Java Modularity initiative as currently defined in the JSR 294 community (of which he is a member) and how to fix it.

The new features in R4.2 are spread across the Core and Compendium parts of the , but the major changes in R4.2 are being driven by enterprise requirements, primarily represented in the Remote Services (formerly RFC 119) and Blueprint Container (formerly RFC 124) additions to the Compendium. The new service registry hooks in the core were similarly based on enterprise requirements (specifically from the Remote Services work).

But of course not done with the enterprise requirements. The EEG is meeting again next week, primarily to continue working on the Java EE component mappings Peter briefly references, which we hope to publish at the end of the year in an "Enterprise Profile" document, and start thinking about what's going to be in R5, scheduled for June 2010.

And we need to continue working on application metadata and the OSGi Bundle Repository definitions (despite the fact that Peter doesn't want to define an application ;-). The main reason for this is to provide a better foundation for the kind of development lifecycle tooling commonly used for enterprise application development.

We have made a good start, but there's lots more to do. Meanwhile the debate continues about whether or not it's a good idea to use OSGi for developing enterprise applications directly, or only indirectly through its incorporation in products.

R4.2 represents a significant step in this direction, but we still have a lot to do.