What's the correct procedure for managing OSGi bundle dependencies?

Question

I'm about to start working on an application that I'd like to run in an OSGi container, like Virgo. Virgo's core platform supplies many of the dependencies I'm interested in, like the Spring Framework, but I'd also like to use Spring Integration. Spring Integration's jars are ready-to-go OSGi bundles, and are available to me along with many other third-party dependencies in an Ivy repository.

To tell the OSGi container that my bundle depends on, say, Spring Integration, I need to add relevant packages or bundles to my Manifest -- I know how to do this and understand how that works.

What I'd like to understand is how to develop against, resolve, build and eventually deploy third-party bundles available in some kind of repository (preferably Ivy). In the past I've accomplished this in two ways:

1. Add the dependencies to the target platform, or in this case, the Virgo ext repository
2. Keep a copy of the dependency in my workspace, export it as part of the build

Neither of these solutions seem scalable or especially elegant.

I'm interested in using Virgo 3.0.0 or Equinox and my development environment is Eclipse, if a different OSGi container or development environment will make my life easier, I'm happy to switch.

To make this crystal clear, I'd like to know:

1. How do I develop against OSGi bundles in an external repository (e.g. the bundles live in Ivy)?
2. How do I build and deploy my bundle along with its required external dependencies?

Answer 1

You can define an external Virgo repository to point at a local copy of an Ivy repo as explained in the Virgo User Guide under "Configuring the Local Provisioning Repository". This repository can also be used when Virgo is launched from Eclipse.

Note that we are working on p2 integration for Virgo 3.5 and this will give you some further options.

Answer 2

AFAIK that is implementation specific. If you are using Equinox, then p2 is the provisioning system you are looking for. I would assume that other implementations would have their own methods/tools for accomplishing similar functionality.