You can always look in your own bundle first, I cannot see how that could harm.
Seems also nice to be able to override things.
Kind regards,
Peter Kriens
> On 29 May 2017, at 23:29, Mark Raynsford <list+org.o...@io7m.com> wrote:
>
> 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
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
