Over the last month or so I have been working on adding OSGi Bundle Repository (OBR) support to Nexus Professional, and I am happy to announce this feature will be available in the 1.3.5 release. But what exactly is OBR and why should you care?
OBR has been around since 2006, it defines a small XML schema and Java API that allows clients to discover and deploy OSGi bundles by matching capabilities with requirements. Distributors provide XML describing their bundles, and this is used by OBR service implementations running on OSGi frameworks. Management clients talk to their local OBR service using the Java API.
Here’s a concrete example, the Apache Felix project has XML describing their bundle releases:
They also provide an OBR service implementation that works on any R4 OSGi framework:
<dependency> <groupId>org.apache.felix</groupId> <artifactId>org.apache.felix.bundlerepository</artifactId> <version>1.4.0</version> </dependency>
Let’s see OBR in action!
- Go to http://felix.apache.org/site/downloads.cgi and download the 1.8.0 distribution
- Extract Felix 1.8.0 to a local temporary directory
java -jar bin/felix.jar
You should see the Felix command shell, type obr to see the available OBR commands:
Welcome to Felix. ================= -> obr obr help [add-url | remove-url | list-url | list | info | deploy | start | source | javadoc] obr add-url [<repository-file-url> ...] obr refresh-url [<repository-file-url> ...] obr remove-url [<repository-file-url> ...] obr list-url obr list [-v] [<string> ...] obr info <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ... obr deploy <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ... obr start <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ... obr source [-x] <local-dir> <bundle-name>[;<version>] ... obr javadoc [-x] <local-dir> <bundle-name>[;<version>] ...
This service is pre-configured to use the Felix OBR, to see a list of released bundles type:
-> obr list Apache Felix Bundle Repository (1.2.1, ...) Apache Felix Configuration Admin Service (1.0.4, ...) Apache Felix Declarative Services (1.0.8, ...) Apache Felix EventAdmin (1.0.0) Apache Felix File Install (1.2.0, ...) Apache Felix HTTP Service Jetty (1.0.1, ...) Apache Felix iPOJO (1.2.0, ...) Apache Felix iPOJO (0.8.0) Apache Felix iPOJO Arch Command (1.2.0, ...) Apache Felix iPOJO Composite (1.2.0) Apache Felix iPOJO Composite (1.0.0, ...) Apache Felix iPOJO Event Admin Handler (1.2.0, ...) Apache Felix iPOJO Extender Pattern Handler (1.2.0) Apache Felix iPOJO Extender Pattern Handler (1.0.0, ...) Apache Felix iPOJO JMX Handler (1.2.0, ...) Apache Felix iPOJO Temporal Service Dependency Handler (1.2.0, ...) Apache Felix iPOJO White Board Pattern Handler (1.2.0, ...) Apache Felix Log Service (1.0.0) Apache Felix Metatype Service (1.0.2, ...) Apache Felix Prefrences Service (1.0.2) Apache Felix Remote Shell (1.0.2) Apache Felix Shell Service (1.0.2, ...) Apache Felix Shell TUI (1.0.2, ...) Apache Felix UPnP Base Driver (0.8.0) Apache Felix UPnP Extra (0.4.0) Apache Felix UPnP Tester (0.4.0) Apache Felix Web Management Console (1.2.10, ...) OSGi OBR Service API (1.0.0) OSGi R4 Compendium Bundle (4.0.0) Servlet 2.1 API (1.0.0) ->
Say we’re interested in the Felix Web Management Console, to deploy and start this bundle type:
-> obr start 'Apache Felix Web Management Console' Target resource(s): ------------------– Apache Felix Web Management Console (1.2.10) Required resource(s): --------------------– Apache Felix HTTP Service Jetty (1.0.1) OSGi R4 Compendium Bundle (4.0.0) Apache Felix Log Service (1.0.0) Apache Felix Declarative Services (1.0.8) Deploying...org.mortbay.log:Logging to org.mortbay.log via org.apache.felix.http.jetty.LogServiceLog org.mortbay.log:Init SecureRandom. done. ->
Notice the OBR service was able to deduce we needed other bundles to successfully run the Web Management Console, and it automatically deployed and started them as well. To prove that the Web Console is now up and running, go to http://localhost:8080/system/console/ and log on using admin as both the user-id and password.
That should have given you a taste of OBR, but how does this relate to Nexus Professional?
Well with Nexus Pro 1.3.5 you will be able to:
- dynamically generate OBR metadata for your existing repositories
- proxy and cache remote OBRs, including both metadata and bundles
- host local OBRs and deploy bundles into them using the UI or Maven
- group all of the above types of OBRs into a single merged OBR
- apply CRUD privileges to control access to particular bundles
Basically the same things you can do with Maven and P2 repositories you can now do with OBR!
This screencast shows how you can quickly build up and use OBR metadata using Nexus Professional 1.3.5. We have also been able to reconstruct the OSGi Alliance repository in a matter of minutes by proxying known public sites and grouping them into a single OBR.
What does the future hold for OBR? Well although it’s existed as a draft specification since 2006, it has not yet been formally standardized by the OSGi Alliance. Since then alternative approaches have appeared, such as P2. The OSGi Alliance have therefore decided to revisit the original requirements and see where OBR can be improved, given what we know now about deploying large applications in OSGi.
So the final OBR specification might vary from the current draft, but if you use Nexus Professional to manage and generate your OBR metadata this shouldn’t bother you. The repository abstraction in Nexus makes it very easy to add support for new metadata formats, which means we will be able to support both the old and new formats as required.