felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Programmatic/non-shell-based interface to OBR
Date Wed, 29 Nov 2006 19:27:42 GMT

I am not really sure I understand the issue as you describe it. The 
bundle repository does not depend on the Felix shell in any way. There 
is a shell command created so that we can have a simple shell-based UI, 
but that is that.

The API for OBR is defined by the org.osgi.service.obr package, which 
was defined at http://bundles.osgi.org/rfc-0112_BundleRepository.pdf, 
but this link appears to be broken now. Peter?

As for the _deploy() method, it is just using the defined API from the 
above package to provide a shell-based UI. All it does is parse the 
command line, get an OBR resolver, add the bundles specified from the 
parsed command line to the resolver, call resolve to resolve any 
dependencies, then call deploy if the dependencies are resolved.

Most of the code is just printing status information to stdout.

So, that is basically the standard algorithm for using the OBR API:

   1. Get a resolver.
   2. Add desired resources to the resolver (discovered through the
      repository admin interface).
   3. Resolve the resolver's set of resources.
   4. Deploy if successfully resolved, print error message if not.

This approach is also used to create a GUI front-end for OBR (which 
hasn't been committed due to lack of time); the OBR GUI doesn't have 
anything at all to do with the shell.

What else specifically do you need? Besides documentation... :-)

-> richard

Steven E. Harris wrote:
> First off, I need to thank the Felix developers for a great
> product. I've been able to integrate the Felix OSGi framework into my
> project with just a few days of study and experimentation.
> A difficult requirement in my project involves discovery and
> resolution of plugin dependencies. The client application needs to be
> able to download a plugin (an OSGi bundle), and then figure out which
> other plugins it must download and install before using the first
> plugin. Unlike Eclipse, we'd like to rely on the Import-Package and
> Export-Package header rather than the more explicit but less flexible
> Require-Bundle.
> The bundlerepository bundle contains all the code to do this
> dependency discovery, but it's wrapped up and tangled in with the
> Felix shell. I spent a long time studying
>   org.apache.felix.bundlerepository.ObrCommandImpl
> before I realized that much of the _deploy() method is using
> interfaces from the org.osgi.service.obr package. That suggests that
> there's supposed to be some available programmatic means to do what
> the OBR-related commands offer in the shell.
> Next I found the class
>   org.apache.felix.mosgi.managedelements.obrprobe.ObrProbe
> which implements the ObrProbeMBean interface's deploy() method. This
> implementation looks slimmed down from ObrCommandImpl's _deploy()
> method; I haven't yet figured out the difference between the two,
> beyond using LDAP-style filters in the former.
> Beyond using liberal cut-and-paste, is there some prescribed way for
> an application embedding Felix to incorporate this kind of
> deploy()/_deploy() capability? Searching the Web repeatedly for
> discussion on this topic has only led me back to reading the source
> code.
> Follow-up question: Couldn't most of the bundlerepository bundle be
> teased apart from depending on the shell?

View raw message