Questions about OSGi

[Sigmund Lee <wu...@gmail.com>]

Hi all,

I'm on my way reading OSGi core spec 6.0 right now. here are some questions
confused me:

1. What's the relationship between a bundle's Bundle-Version manifest
header and attribute version of Export-Package manifest header of this
bundle?
2. Why need add Provide-Capability for some namespace(for example, provide
capability for namespace osgi.extender) to bundle's MANIFEST.MF, but do not
need add Provide-Capability for namespace orgi.wiring.package when we are
using Export-Package on this bundle? is that because namespaces under
osgi.wiring.* is special so we do not need to provide them explicitly when
using capability of them, or something else?
3. to be continued...


Thanks.

Regards.

Re: Questions about OSGi

[David Bosschaert <da...@gmail.com>]

Hi Sigmund,

Yes that's the only reason.

Internally in the OSGi framework everything is translated into the generic
requirements and capabilities. So if you use the Wiring API to obtain the
capabilities of a bundle [1] you get all of them using namespaces,
including the osgi.wiring.package etc, but also osgi.identity and
potentially org.osgi.namespace.contract and others via the same API.
The only place where they are not described in a uniform way is in the
MANIFEST.MF, for those historical reasons.

I agree that it would be good to clear this up in the specs :)

Best regards,

David

[1]
https://osgi.org/javadoc/r6/core/org/osgi/framework/wiring/BundleWiring.html#getCapabilities(java.lang.String)

On 30 September 2016 at 05:24, Sigmund Lee <wu...@gmail.com> wrote:

> Hi David,
>
> Thank you so much for clearing things up.
>
> So there is no exception for any namespace, headers like Export-Package,
> Import-Package, Require-Bundle, etc... exists only because they are far
> more earlier imported than the more generic Provide-Capability &
> Require-Capability headers, even though they are parts of
> requirements/capabilities model?
> It's definitely worth clarifying this on the OSGi specifications.
>
>
> Regards,
> Sig
>
>

Re: Questions about OSGi

[Sigmund Lee <wu...@gmail.com>]

Hi David,

Thank you so much for clearing things up.

So there is no exception for any namespace, headers like Export-Package,
Import-Package, Require-Bundle, etc... exists only because they are far
more earlier imported than the more generic Provide-Capability &
Require-Capability headers, even though they are parts of
requirements/capabilities model?
It's definitely worth clarifying this on the OSGi specifications.


Regards,
Sig

Re: Questions about OSGi

[David Bosschaert <da...@gmail.com>]

Hi Sigmund,

On 29 September 2016 at 11:08, Sigmund Lee <wu...@gmail.com> wrote:

> Hi all,
>
> I'm on my way reading OSGi core spec 6.0 right now. here are some
> questions confused me:
>
> 1. What's the relationship between a bundle's Bundle-Version manifest
> header and attribute version of Export-Package manifest header of this
> bundle?
>

There is no relation. A bundle might have version 5.2.1 and export package
org.foo.bar version 1.0.2 and package org.foo.bar.blah in version 2.0.0.
Everything is independently versioned. Exported packages are normally
versioned using semantic versioning that strictly indicate the
compatibility with previous versions. Bundle versions can be more loosely
versioned, e.g. marketing versions can be used there, but some people use
semantic versioning for bundle versions too.


> 2. Why need add Provide-Capability for some namespace(for example, provide
> capability for namespace osgi.extender) to bundle's MANIFEST.MF, but do not
> need add Provide-Capability for namespace orgi.wiring.package when we are
> using Export-Package on this bundle? is that because namespaces under
> osgi.wiring.* is special so we do not need to provide them explicitly when
> using capability of them, or something else?
>

The reason for this is mostly historical. The Provide-Capability header was
introduced quite a while after the Export-Package and Bundle-Version were
introduced. At some point additional 'capabilities' were needed to be
provided by the bundles. Rather than creating a new header for each of
them, the generic Provide-Capability header was introduced, but it's not
used for capabilities that were already provided using existing headers.


> 3. to be continued...
>

... suspense music ...

Hope this helps,

David