How to deploy OSGi apps and dependencies?

Question

OSGi seems to have an excellent benefit of having small deployable artifacts by not wrapping dozens of JAR dependencies into a lib directory. However, I can't find anything that tells me an easy, reliable way to deploy dependencies to a container. For instance, I have an application that uses CXF and several Spring subprojects. If I need to deploy this application to a new Glassfish server, what would be the best way to do so, ensuring that all dependencies get installed?

I'm using Maven, and it would seem that there could be some way to have a hook that looks at the META-INF/maven directory and pulls the dependency list from the pom.xml and goes and fetches the required libs (probably from a local repo). Is there a way to do that?

The Pax plugin sort of sounds like it's doing this, but it seems to be based around boostrapping a Felix container? Which is not what I want, I am dealing with an already running, remote container.

Is there any shot such a thing exists as command line tool as opposed to GUI as well?

Answer 1

If you create an OSGi application and a classic Java application that do the same thing and use the same libraries then you'll need exactly the same set of JARs. The big difference is being able to explicitly define your dependencies (and possibly produce more granular JARs for your application).

There's only one pure OSGi-based server that I know of (Eclipse's Virgo, previously Spring's DM Server). Glassfish and Websphere have support for OSGi, but I haven't played with them so I can't say much. What I can say is that all of them require an OSGi container and that's usually Eclipse's Equinox or Apache's Felix.

Your question seems to really be about provisioning the application (working out what needs to be deployed). I know that for Maven 3.0 they've done a bunch of stuff working with Eclipse's P2 provisioning framework.

For your application are you deploying an EAR or WAR? For either of those, your build system will need to produce the archive with all dependencies or it won't work. It's a bit confusing on why you have a problem because people use Maven because it does the transitive dependency management for their builds.

Answer 2

There are a number of ways to deploy dependent bundles to OSGi containers. Here are some of them:

1 The Felix OBR bundle repository

You first need to create an XML index file for your available bundles, using a tool such as bindex. If you are using the maven-bundle-plugin, then it automatically maintains an OBR index in ~/.m2/repository/repository.xml.

Load the index using the OBR command-line interface:

> obr:addUrl file:/Users/derek/.m2/repository/repository.xml

Then ask OBR to deploy your target bundle, with dependencies determined from the OBR index:

> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
   Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)

Required resource(s):
---------------------
   Paremus Command API (1.0.23.SNAPSHOT)

Optional resource(s):
---------------------
   Paremus Config Admin Commands (1.0.23.SNAPSHOT)
   Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)

2 Apache Karaf

Karaf supports "features", which are basically lists of bundles required to provide the feature:

karaf@root> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
  mvn:org.apache.felix/org.apache.felix.bundlerepository/1.6.4
  mvn:org.apache.karaf.shell/org.apache.karaf.shell.obr/2.0.0
  mvn:org.apache.karaf.features/org.apache.karaf.features.obr/2.0.0

karaf@root> features:install obr

3 Eclipse Virgo

Virgo uses plans to define the artifacts that comprise an application and it is able to automatically supply the dependencies of an application including bundles, plans, plan archives (PARs), and configurations, from both local and remote repositories.

4 Paremus Nimble

Nimble uses OBR (or its own extended) repository indexes, to automatically deploy all dependent bundles needed to activate a target bundle (and uninstalls them when the target bundle is stopped). It can also detect other dependencies, such as a WAB bundle requires a web-extender and automatically install one according to a configurable policy.

Nimble can also be configured to launch Glassfish, so that its features are available to bundles in the Glassfish container.

The example below also shows that logging support is automatically installed when sshd is activated:

$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run com.paremus.posh.sshd@active
-- sorted parts to install --
4325   osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729   osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727   osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797   osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792   osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436   osgi.resolved.bundle/org.apache.mina.core:2.0.0.RC1
6533   osgi.resolved.bundle/sshd-core:0.3
398   osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396   osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT

(disclaimer: I'm a developer at Paremus)

5 Apache Felix Gogo

gogo is the new RFC147 standard command-line shell. It is already used in Felix, Karaf, Nimble and will soon be available in Glassfish.

Gogo allows you to run any commands that you could type interactively, as a script. So you could generate the list of bundles to install and convert it to a script, or even capture the installed bundles from a working configuration so that it can be re-created from a clean start.