To be revealed at EclipseCon

OSGi Core and Enterprise 5 specifications close

Chris Mayer

Peter Kriens last release for OSGi Alliance is a big one – OSGi Release 5 ushers in the long-awaited OSGi Requirement-Capability model

On the OSGi Alliance blog, the departing OSGi Alliance Director of Technology, Peter Kriens revealed that the finishing touches to his swansong – OSGi Release 5, which some might say is Kriens’ magnum opus.

Kriens added that brand new Core and Enterprise specifications would become available in due course, once they’d passed the eyes of the Expert Group and various lawyers. Fortunately for those within the Eclipse community get to see a draft of it at next week’s EclipseCon/OSGi DevCon. The biggest part of OSGi Release 5 - the long-awaited OSGi Requirement-Capability model according to the evangelist for OSGi.

Detailing the amount of work that had gone into creating a generic model for dealing with Java dependencies, Kriens spoke of why a change was needed:

Our industry did not have a way to describe these myriad of dependencies so the solution was a proliferation of profiles. Instead of having 100 dependencies you only had one. Unfortunately, that single dependency aggregated a thousand dependencies, 900 of which you could not care less about. Oh yeah, and it lacked one dependency you actually really, really, required. Profiles are the siren song of software, they lure us with a simple solution that is surprisingly wrong. 

In steps RFC 112 OSGi Bundle Repository (OBR) to completely change the way of thinking, where Kriens and Richard S. Hall developed a language to express capabilities and requirements. OSGi began to describe dependencies and the model became incredibly useful for developers in a pickle, especially when in the extender.

Kriens adds:

Each bundle becomes completely self-describing with the Requirement-Capability model. This enables the holy grail of automatic assembly of components (well, ok, almost). From a resource it is now possible to find the minimum set of transitive dependencies automatically, even taking local capabilities into account.  For me the greatest advantage of this model is that it voids the need for “applications”. Any bundle can be an “application” since any dependencies can now automatically be included.

Keeping his cards close to his chest, Kriens revealed some of the new tidbits to Release 5 such as a generic API that is used by a Resolver service and a Repository service. The Resolver service provides access to an OSGi-aware resolver that can take resources and find the closure of a set of resources whilst the Repository service provides access to local or external repositories.

As previously reported, Kriens is leaving the OSGi Alliance for pastures new but states that the Requirement-Capability model is ‘the most innovative piece since services’ within OSGi. He also says he may dabble with it in the future, despite not being active within the OSGi Alliance. 

We wish Peter well in his future endeavours, whatever they may be. This last release will certainly cement his legacy playing a huge part in the adoption of the revolutionary dynamic module system OSGi.

Inline Feedbacks
View all comments