Why Bnd does not generate Capability and Requirement for all the framework Headers?

[Clément Delgrange]

Hi,

The Provide-Capability and the Require-Capability headers can represent other OSGI manifest headers such as Export-Package, Import-Package, Bundle-SymbolicName,... but bnd only generate capabilities for things that do not have a headers such as "osgi.service".

Why bnd does not generate capabilities for imported package for example ?

Thanks,
Clement.

[Raymond Auge]

The capabilities/requirements for those things are implied.

Since the wiring API was introduced the framework does actually represent it that way.

The resolver works that way.

If you look at a bundle's metadata once it's been indexed by an implementation of the R5 repository spec then it looks that way.

So the bundle manifest isn't represented this way for 3 reasons that I can think of (i'm sure others will correct me otherwise):

- standards (the osgi specs says how the metadata must appear in the manifest and nobody likes to duplicate data so why dup in the caps&reqs)

- legacy/backward compatibility

- readability (to keep humans happy; reading caps&reqs can get daunting as the size and complexity grows)

Sincerely,

- Ray

Thanks,
Clement.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Tim Ward]

As a further addendum, using Require/Provide capability for the osgi.wiring.package and osgi.wiring.bundle namespaces is forbidden by the specification. If bnd did generate these things then the resulting bundle would be in violation.

Tim

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

[Clément Delgrange]

Do you know why it is forbidden?

What I understand is that caps & reqs is the representation for automated tools and other headers for human, is that true ? In this case, why OSGI does not provide an header for osgi.service, osgi.implementation,... ? In the other case, if OSGI wants this generic representation why they do not allow tools to generate headers in htis form in a transition step ? 

Le jeudi 21 décembre 2017 17:38:58 UTC+1, Tim Ward a écrit :

As a further addendum, using Require/Provide capability for the osgi.wiring.package and osgi.wiring.bundle namespaces is forbidden by the specification. If bnd did generate these things then the resulting bundle would be in violation.

Tim

On 21 Dec 2017, at 16:35, Raymond Auge <raymon...@liferay.com> wrote:

On Thu, Dec 21, 2017 at 11:17 AM, Clément Delgrange <cl.del...@gmail.com> wrote:

Hi,

The Provide-Capability and the Require-Capability headers can represent other OSGI manifest headers such as Export-Package, Import-Package, Bundle-SymbolicName,... but bnd only generate capabilities for things that do not have a headers such as "osgi.service".

Why bnd does not generate capabilities for imported package for example ?

The capabilities/requirements for those things are implied.

Since the wiring API was introduced the framework does actually represent it that way.

The resolver works that way.

If you look at a bundle's metadata once it's been indexed by an implementation of the R5 repository spec then it looks that way.

So the bundle manifest isn't represented this way for 3 reasons that I can think of (i'm sure others will correct me otherwise):

- standards (the osgi specs says how the metadata must appear in the manifest and nobody likes to duplicate data so why dup in the caps&reqs)

- legacy/backward compatibility

- readability (to keep humans happy; reading caps&reqs can get daunting as the size and complexity grows)

Sincerely,

- Ray

Thanks,
Clement.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Tim Ward]

On 21 Dec 2017, at 16:55, Clément Delgrange <cl.del...@gmail.com> wrote:

Do you know why it is forbidden?

Historical reasons.

What I understand is that caps & reqs is the representation for automated tools and other headers for human, is that true ? In this case, why OSGI does not provide an header for osgi.service, osgi.implementation,... ? In the other case, if OSGI wants this generic representation why they do not allow tools to generate headers in htis form in a transition step ? 

Import-Package, Export-Package, Require-Bundle and Fragment-Host have all existed for a long time, much longer than Provide/Require capability. There are therefore a great many bundles in the universe that use these headers and know nothing of Provide/Require Capability. Rather than defining a potentially duplicative (and conflicting) alternative for something that already had wide support among implementations, tools and frameworks the decision was made not to replace the use of Import-Package et al.

The result is that Provide/Require Capability are used to model everything at runtime, and in the repository, but the framework continues to process the *original* definitions of these dependencies.

Tim

[Neil Bartlett]

I think there is a further reason we don't use Require/Provide-Capability for Import/Export-Package, Require-Bundle and Fragment-Host: each of these have effects in terms of the class space of the bundle, implemented as specific processing built-in to the OSGi Framework.

With Require-Capability in a namespace like osgi.extender or osgi.service, the Framework doesn't really do anything beyond making sure that a matching capability exists. However with Import-Package, the framework ensures that a matching export exists and additionally creates a ClassLoader delegation path from the importing to the exporting bundle. Similarly with Require-Bundle and Fragment-Host.

Bundle-NativeCode is another example of a requirement that has special processing beyond just making sure that a matching capability exists.

Neil

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.

[Clément Delgrange]

Thanks for the explanation, when we have to debug resolution this is not so easy when we are not used to caps & reqs.