What kind of “friendly” Blueprint behaviour are you looking for? Since you
specified effective:=active on your R-C header, it will always be ignored by
the OSGi Framework itself. So I assume you’re thinking about tooling, like the
resolve panel in Bndtools?
You can of course write Require-Capability headers exactly like this if you
wish. Also in theory we could get bnd to generate them by reading the blueprint
XML files. Currently bnd doesn’t do this, but we once did something similar in
repoindex for DS-based bundles, the principle being pretty much the same.
However this turned out to create more problems than it solved. If we resolve
the osgi.service namespace then it forces the required service to be provided
in the *same* framework. However we might want to provide it from a remote
framework using Remote Services Admin. For this reason Bndtools has an option
to ignore the osgi.service namespace, treating it as non-effective, as follows:
-resolve.effective: active; skip:="osgi.service"
Regards,
Neil
> On 13 Jan 2015, at 00:36, Raymond Auge <[email protected]> wrote:
>
> Hey All,
>
> I have a (hopefully not completely stupid) question about blueprint and
>
> Require-Capability: osgi.service;filter:="(...)";effective:=active
>
> Could blueprint be made to behave a little more friendly by using a
> require-cap on a service which the blueprint context depends on?
>
> - Ray
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
