Steven E. Harris wrote:
Richard S. Hall <[EMAIL PROTECTED]> 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.
You apparently removed my smiley on that line...
Just keep in mind that there is difference between being dependent on a
framework or being dependent on a bundle. Being dependent on a framework
is not so good because you are stuck with the framework, being dependent
on a bundle is not so bad, because it can run on any framework.
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.
If you use OBR to try to resolve your bundles, then you can get more
information about why it cannot resolve.
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.
Seems like it would be better to just have:
public static Resource convertToResource(Bundle bundle);
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 think the issue there was to not become dependent on a specific filter
type. You could imagine OBR implementations that used a different filter
representation.
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.
Well, OBR was intended to be a little more generic than the framework,
although I have done some work to merge how OBR and Felix work...that is
still in the works, though.
-> richard
