Re: [equinox-dev] Provide capability question

[Lars Vogel <lars.vogel@xxxxxxxxxxx>]

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 <njbartlett@xxxxxxxxx> wrote:
>
>> On 21 Feb 2016, at 19:39, Lars Vogel <lars.vogel@xxxxxxxxxxx> 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: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> 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
> equinox-dev@xxxxxxxxxxx
> 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: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com