felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven E. Harris" <...@panix.com>
Subject Re: Programmatic/non-shell-based interface to OBR
Date Thu, 30 Nov 2006 16:07:24 GMT
Richard S. Hall <heavy@ungoverned.org> writes:

> You seem to like to accuse things of being Felix-specific.

Hey, I have nothing against Felix. I was just elated to discover how
much of it can be used through the OSGi interfaces, which alleviates
the sense of my application depending on a particular implementation.

> I will try to look into it, but the approach should work on non-Felix
> frameworks. Just copy how OBR creates a local resource and put that
> code into your own project...it is open source after all. :-)

> at a minimum, Felix' OBR impl could just export a simple utility
> package and expose a class for doing it. At worst, this approach
> would be Felix OBR impl specific...

I've been thinking about this last night and this morning, and there
are a few gaps that would be beneficial to plug.

First, there's no way to figure out why an installed bundle can't be
resolved. Calling bundle.start() might throw a BundleException, but
there's not enough of an interface to figure out what to else needs to
be installed.

Second, some of the first problem could be solved if one could produce
a set of Requirements from a Bundle. Unfortunately these two concepts
live in separate realms: Requirements are OBR-related, and Bundles
don't know anything about Requirements. Maybe there could be some
utility class -- for lack of an obvious home in one of the OBR
interfaces -- that could provide a function like:

   public static Requirements[] getRequirements(Bundle bundle);

Then one would need to combine each of these requirements into a
single filter expression to feed to
RepositoryAdmin.discoverResources(), which leads us to the next point.

Third, the RepositoryAdmin would do well with an overloaded
discoverResources() function that takes a Filter as an argument. If
one already has a Requirement or Filter in hand, the
discoverResources() method wouldn't have to reparse the filter
string. Along these lines, perhaps Requirement.getFilter() should
return a Filter, not a String.


I can see that the OBR interfaces emerged after the OSGi Framework
interfaces, but there are several concepts in the OBR package that we
could make good use of in the base Framework as well.

Please let me know what you think about the proposals above.

-- 
Steven E. Harris

Mime
View raw message