So far, we have mentioned OBRs a few times without really diving into them. We're now at a point where we need to start using them, so it's time to take that dive.
In this chapter, we will first have a look at the OBR service in some level of detail, and then we'll see how we use it to install bundles from a remote location onto our Felix framework. We'll use the bundles we've created in Chapter 5, The Book Inventory Bundle, to practice what we've learned.
By the end of this chapter, you will have:
- Learned about the OSGi Bundle Repository concepts and the OBR repository XML file format
- Inspected the local releases repository
- Installed the bundles from Chapter 5 onto Felix
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.
Note
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 chapter, we will cover those commands. API-based interaction with the service is not covered, as it is beyond the scope of this book.
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:
Those may be of use later, as a source for the dependencies of your project.
We already have an OBR repository available to us, our releases repository. We have deployed the bookshelf bundles to it in the previous chapter as part of the Maven deploy phase (file:///C/projects/felixbook/releases/repository.xml).
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.packtpub.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.
In Chapter 5, we had briefly looked at how to deploy a bundle to a remote repository using Maven. The Felix Maven Bundle Plugin attaches to the deploy phase to automate the bundle deployment and the update of the repository.xml file.