I have a work-in-progress implementation that does the following: Bundle B declares:
Provide-Capability:\
com.io7m.callisto.package;\
name:String=a.b.c;
version:Version=1
This is analogous to the standard Export-Package header.
This above definition "exports" the package "a.b.c". When B is processed
by the bundle tracker, the tracker sees the above export and inspects
"/a/b/c/package-info.cpd". The package-info.cpd file contains a list
of resources that will be exported along with their "resource
identifiers". An example package-info.cpd file:
package a.b.c
resource hello0 text something.txt
resource hello1 image example.png
The above declares that two resources will be exported with
identifiers a.b.c.hello0 and a.b.c.hello1. The bundle tracker resolves
the given relative filenames to their full bundle resource URLs, and
builds and maintains a map of the resources exported by each bundle
being tracked.
Bundle C declares:
Require-Capability:\
com.io7m.callisto.package;\
filter=(&(name=a.b.c)(version>=1)(version<2))
When C wants to access resource a.b.c.hello0, the ResourceResolver
service inspects the wires of C in namespace com.io7m.callisto.package
and picks the wire that provides ("exports") package a.b.c to C. A
wire is guaranteed by the OSGi resolver to exist if C has correctly
"imported" a.b.c using the above Require-Capability definition. The
resource is resolved from bundle B.
This all works well except for one small issue... Bundles must manually
require their own exported packages if they want to resolve their own
resources via the ResourceResolver service. The OSGi resolver
(correctly) won't wire a bundle to itself if it doesn't specify a
Require-Capability header that effectively requires its own packages.
I could probably manually add in a hack to try resolving a resource
directly from the requesting bundle first, and then falling back to the
proper resolution path above if the bundle doesn't export the target
package, but this feels untidy. I'm not sure if I'd accidentally be
subverting the work that the OSGi resolver has done.
It seems unpleasant for users to have to redundantly "import" their own
packages. Is there a better way to handle this?
M
pgpDxcTQSWM_N.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
