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. > 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
