Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
Thanks for the suggestions so far.
I think I slightly modified the original OBR interfaces, though, but
we can probably deal with that by extending the original interface
definitions.
This looks easy to achieve.
Regardless, this means that it may now be possible to use
ManifestParser to convert manifests to capabilities/
requirements...or at least it will be in the future. So, we have an
option now of using the existing OBR approach or adopting the
ManifestParser if it will be sufficient (or moving in that direction
later if need be).
I started looking into using ManifestParser. A problem arises with the
ManifestParser constructor. First, I need to get ahold of a
PropertyResolver instance. The Felix class exposes one with
getConfig(), but I can't get back "out" to Felix from within one of my
bundles.
The logger and headerMap parameters are easy enough to provide. If I
knew how to get a PropertyResolver from within a bundle, I could start
experimenting with using ManifestParser to write the Bundle->Resource
conversion function.
You don't need to get the PropertyResolver that Felix uses, you can
create your own instance...it is essentially a map. The only thing that
it is used for is to determine that matching set of libraries from the
available libraries. It essentially examines osname and processor to
determine which of the available native code libraries are appropriate
for the current platform.
In truth, we could avoid passing this into the constructor and pass it
into the getLibraries() instead, then you wouldn't need it at all, since
you don't need to call this method for converting a bundle to a
resource. In this case, ManifestParser is also helping out with some
runtime issues. We might find that some of this stuff has to be cleaned
up to some degree.
Admittedly, ManifestParser is still a little bit rough around the edges
for this purpose, but it definitely has the basics. It currently has the
ability to:
* Convert bundle symbolic name and package export to capabilities.
* Convert require-bundle and package import to requirements.
At a minimum, it still needs a mechanism to convert native code headers
to requirements.
-> richard
