OSGi and Apache Felix 3.0 Beginner’s Guide
Introduction
The OSGi Bundle Repository (OBR) is a draft specification from the OSGi alliance for a service that would allow getting access to a set of remote bundle repositories. Each remote repository, potentially a front for a federation of repositories, provides a list of bundles available for download, along with some additional information related to them.
The access to the OBR repository can be through a defined API to a remote service or as a direct connection to an XML repository file.
The bundles declared in an OBR repository can then be downloaded and installed to an OSGi framework like Felix. We will go through this install process a bit later.
The OSGi specification for OBRs is currently in the draft state, which means that it may change before it is released.
The following diagram shows the elements related to the OBR, in the context of the OSGi framework:
The OBR bundle exposes a service that is registered with the framework. This interface can be used by other components on the framework to inspect repositories, download bundles, and install them.
The Gogo command bundle also registers commands that interact with the OBR service to achieve the same purpose. Later in this article, we will cover those commands. API-based interaction with the service is not covered, as it is beyond the scope of this article.
The OBR service currently implements remote XML repositories only. However, the Repository interface defined by the OBR service can be implemented for other potential types of repositories as well as for a direct API integration.
There are a few OSGi repositories out there, here are some examples:
- Apache Felix: http://felix.apache.org/obr/releases.xml
- Apache Sling: http://sling.apache.org/obr/sling.xml
- Paremus: http://sigil.codecauldron.org/spring-external.obr and http://sigil.codecauldron.org/spring-release.obr
Those may be of use later, as a source for the dependencies of your project.
The repository XML Descriptor
We already have an OBR repository available to us, our releases repository.
Typically, you’ll rarely need to look into the repository XML file. However, it’s a good validation step when investigating issues with the deploy/install process.
Let’s inspect some of its contents:
<repository lastmodified=’20100905070524.031′>
Not included above in the automatically created repository file is the optional repository name attribute.
The repository contains a list of resources that it makes available for download. Here, we’re inspecting the entry for the bundle com.packt.felix.bookshelf-inventory-api:
<resource
id=’com.packtpub.felix.bookshelf-inventory-api/1.4.0′
symbolicname=’com.packtpub.felix.bookshelf-inventory-api’
presentationname=’Bookshelf Inventory API’
uri=’file:/C:/projects/felixbook/releases/com/packtpub/felix/
com.packtpub.felix.bookshelf-inventory-api/1.4.0/com.packtpub.felix.
bookshelf-inventory-api-1.4.0.jar’
version=’1.4.0′>
<description>
Defines the API for the Bookshelf inventory.</description>
<size>7781</size>
<category id=’sample’/>
<capability name=’bundle’>
<p n=’symbolicname’
v=’com.packtpub.felix.bookshelf-inventory-api’/>
<p n=’presentationname’ v=’Bookshelf Inventory API’/>
<p n=’version’ t=’version’ v=’1.4.0’/>
<p n=’manifestversion’ v=’2’/>
</capability>
<capability name=’package’>
<p n=’package’
v=’com.packtpub.felix.bookshelf.inventory.api’/>
<p n=’version’ t=’version’ v=’0.0.0’/>
</capability>
<require name=’package’
filter=
‘(&(package=com.packtpub.felix.bookshelf.inventory.api))’
extend=’false’ multiple=’false’
optional=’false’>
Import package com.packtpub.felix.bookshelf.inventory.api
</require>
</resource>
Notice that the bundle location (attribute uri), which points to where the bundle can be downloaded, relative to the base repository location. The presentationname is used when listing the bundles and the uri is used to get the bundle when a request to install it is issued.
Inside the main resource entry tag are further bundle characteristics, a description of its capabilities, its requirements, and so on.
Although the same information is included in the bundle manifest, it is also included in the repository XML for quick access during validation of the environment, before the actual bundle is downloaded.
For example, the package capability elements describe the packages that this bundle exports:
<capability name=”package”>
<p n=”package” v=”com.packtpub.felix.bookshelf.inventory.api”/>
<p n=”version” t=”version” v=”0.0.0″/>
</capability>
The require elements describe the bundle requirements from the target platform:
<require extend=”false”
filter=”(&(package=com.packtpub.felix.bookshelf.inventory.
api)(version>=0.0.0))”
multiple=”false” name=”package” optional=”false”>
Import package com.packtpub.felix.bookshelf.inventory.api
</require>
</resource>
<!– … –->
</repository>
The preceding excerpts respectively correspond to the Export-Package and Import-Package manifest headers.
Each bundle may have more than one entry in the repository XML: an entry for every deployed version.
Updating the OBR repository
The Felix Maven Bundle Plugin attaches to the deploy phase to automate the bundle deployment and the update of the repository.xml file.
Using the OBR scope commands
The Gogo Command bundle registers a set of commands for the interaction with the OBR service. Those commands allow registering repositories, listing their bundles, and requesting their download and installation.
Let’s look at those commands in detail.
