Thanks Neil for the detailed answer. For a customer OSGi service which is required at runtime by another customer plug-in, would you say that it is good practice to model this requirement via capabilities?
Best regards, Lars On Sun, Feb 21, 2016 at 9:00 PM, Neil Bartlett <[email protected]> wrote: > >> On 21 Feb 2016, at 19:39, Lars Vogel <[email protected]> wrote: >> >> Hi, >> >> I have two question about Provide capability and Require-Capability. >> >> Background: you declare that you provide ds in version 1.2 via the >> following snippet in your MANIFEST.MF >> >> Provide-Capability: osgi.extender; >> osgi.extender="osgi.component"; >> version:Version="1.2"; >> uses:="org.osgi.service. >> >> A plug-in which requires his capablitiy defines the following: >> >> Require-Capability: osgi.extender; >> filter:="(&(osgi.extender=osgi.component)(version>=1.2)(!(version>=2.0)))" >> >> The first question is: Where is this defined that these are the >> correct entries? I use >> http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=cff4c8e643032ce870dfc9e8279cd5fb16218f4e >> to "remember" the correct way to define it, but I guess there is a >> more general way. > > > For DS, see OSGi Compendium Specification R6, section 112.9.7. > > Other OSGi specs also define the capabilities that should be declared by > their providers. For example, section 105.12 declares the correct capability > for the Metatype Service. Unfortunately, adding sections like this requires a > bump of the specification version, so it has not been done universally for > all specs… instead, the section is added opportunistically when the spec > needs to be updated for other reasons. > > >> >> The second question is. What is the correct way to use >> Provide-Capability and Provide-Capability for my customer code? In my >> example, I provide a service via DS and want to ensure that the >> consumer is only started if the service is available. I think >> Require-Capability is the correct way, but I have not seen an example >> for a customer capability yet. > > For a service you can use the osgi.service namespace… see compendium section > 135.4. The type of the service should be declared with the objectClass > attribute. For example on the provide side: > > Provide-Capability: osgi.service; objectClass=org.example.IFoo > > … and on the consume side: > > Require-Capability: osgi.service; > filter:=“(osgi.service=org.example.IFoo)”; effective:=active > > However you should be VERY careful with this for this following reasons: > > 1. Not every bundle providing a service actually declares it via the > osgi.service capability. Particularly this is true for bundles that provide > the service programmatically rather than via DS or some other declarative > framework. > 2. Even bundles that declare they provide a service don’t always *actually* > provide it. For example they may only provide it some of the time, or under > certain conditions. The declaration of a provided service is therefore > nothing more than the *potential* to provide it. > 3. Services can be provided remotely using OSGi Remote Services. Therefore if > you put in a requirement for a service and use a resolver like the one in > Bndtools to assemble your application, then you will force the provider of > the service to be installed locally when you might have wanted it to be > remote. > > For these reasons, the Bndtools resolver usually ignores requirements in the > osgi.service namespace. > > Regards, > Neil > > >> >> Best regards, Lars >> >> -- >> Eclipse Platform UI and e4 project co-lead >> CEO vogella GmbH >> >> Haindaalwisch 17a, 22395 Hamburg >> Amtsgericht Hamburg: HRB 127058 >> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel >> USt-IdNr.: DE284122352 >> Fax (040) 5247 6322, Email: [email protected], Web: >> http://www.vogella.com >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Eclipse Platform UI and e4 project co-lead CEO vogella GmbH Haindaalwisch 17a, 22395 Hamburg Amtsgericht Hamburg: HRB 127058 Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel USt-IdNr.: DE284122352 Fax (040) 5247 6322, Email: [email protected], Web: http://www.vogella.com _______________________________________________ equinox-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/equinox-dev
