The OSGi Alliance have released the specifications for Release 5 of their namesake framework, standardising the OSGi Bundle Repository (known as OBR), using the generic capability requirements model, and introducing programmatic access to version ranges. The specifications can be downloaded, and will be implemented by the upcoming release of Equinox 3.8 available in June, as well as Apache Felix 4.0.
Although the version number indicates a major change to OSGi, in fact the changes are relatively minor. A feature which was implemented (but did not become part of the specification) necessitated the change; the OSGi R5 does not contain –SNAPSHOT handling, as covered by InfoQ previously.
Together with the generic requirements (introduced in last year's OSGi 4.3) , the Enterprise OSGi R5 specification includes the specification for the OBR service, or OSGi Bundle Repository. OBR has been available for many years previously – originally, it was the Oscar Bundle Repository, named for Oscar (which subsequently became Apache Felix) – but without a definitive specification, never found much traction outside Apache Felix. Eclipse P2 provides a similar solution, though at the time, P2 provided support for non-OSGi components (such as the Eclipse launchers) which could not be represented in an OBR repository directly. With the advent of the Require-Capability and Provide-Capability, these may now provide enough additional information to enable P2 and OBR to provide the same level of service.
OSGi bundle repositories have had limited success in the past, whereas Eclipse Update sites over P2 have seen much wider acceptance. Partially, this is due to the popularity of Eclipse as both an IDE and a platform for other products, but has also been limited by the lack of a formal standard for OBR. Bundle repositories such as SpringSource's Enterprise Bundle Repository and Knopflerfish have languished, although OBR enabled runtimes (such as Apache Karaf) have flourished.
Fortunately, embedding the resolver is about to become much simpler, with an OSGi Resolver service providing a standardised means to resolve against a set of requirements. This will allow bootstrap runtimes to define a list of bundles, and to be able to install those bundles on demand into an existing runtime, much like Eclipse update sites operate at the moment.
Other improvements, such as integration with the ServiceLoader class used by non-OSGi applications for decoupled service provision, and a SubsystemsService which provides multi-tenancy in an OSGi runtime are also available.
These join the OSGi Compendium 4.3 and the OSGi Residential 4.3, released last month, which combines previously released specifications (such as the JTA and JPA) into a compendium document. The residential specification is the first of its kind, brining:
The services of this Residential Specification have been designed with the residential market in mind. Requirements and management protocols for this environment are defined in the specifications by consortias like the Home Gateway Initiative (HGI), the Broadband Forum (BBF) and the UPnP Forum. These specifications provide requirements for execution environments in a Consumer Premises Equipment (CPE) and other consumer devices, as well as protocols for the management of residential environments.
Eclipse Equinox 3.8 and Apache Felix 4.0 are expected to be certified OSGi R5 compliant in the coming weeks.