OSGi Compendium

[Felix Meschberger <fm...@gmail.com>]

Hi all,

Currently the Sling launcher (in the launchpad/base module) contains the
Felix framework, the OSGi Core libraries as well as the OSGi Compendium
libraries.

While working on the implementation of the new Declarative Services 1.1
features planned for addition in the OSGi Compendium Specification 4.2 I
ran into a problem with this setup.

Consider a bundle X importing the Declarative Services packages *before*
the new implementation is installed. Both the system bundle (as per the
launchpad/base module) and the Declarative Services implementation
export version 1.0 of the org.osgi.service.component package. This
results in all bundles wiring to the system bundle. Everything is fine.

Now update the Declarative Services bundle which now exports version 1.1
of the org.osgi.service.component package. The Declarative Services
bundle binds to its own export using the latest version available.
Bundle X is still wired to the system bundle because there is no
rewiring taking place.

The consequence is, that the new Declarative Services bundle cannot call
any of the activate or deactivate methods of the components in Bundle X
because the ComponentContext argument is not compatible.

As a fix, I suggest we modify the launchpad/base bundle to *not* provide
the Compendium packages any more. Instead we will expect that either the
Compendium implementation bundles export the packages (as for example
the Apache Felix Declarative Services bundle does) or that the
compendium packages are installed as a bundle.

WDYT ?

Regards
Felix

Re: OSGi Compendium

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger schrieb:
> 
> Carsten Ziegeler schrieb:
>> Dominik Süß wrote:
>>> Wouldn't it be more straight forward to exclude the Compendium Libraries
>>> from the Declarative Services as well and have it as seperate bundle in
>>> general?
>>> I know this thoughts might lead to a big amount of small bundles and some
>>> might not like this, but in this case I think it really would make sense.
>> This actually would require to split up the compendium into the various
>> parts and have an api bundle for each part.
>> Updating the DS then would require to update the api and the impl bundle.
>>
>> Hmm, not sure what the better option is. At least, it seems that pre
>> bundling the compendium libs is wrong. So +1 to remove them from
>> launchpad/base.
>>
>> I like the way how the Apache Felix DS implementation does it. You get
>> one bundle containing everything you need. So updating to a new spec
>> version is pretty simply as the bundle is self contained.
> 
> Actually the Apache Felix DS implementation also exports the
> Configuration Admin packages. This will probably be removed for the next
> release.
> 
>> How do other implementations do this?
> 
> AFAICT the Eclipse/Equinox project is using the approach of not
> including the API in the implementation bundles but to have you install
> the compendium library bundle.
> 
> There are basically two approaches to the question of where to locate
> API with respect to the implementations: One is to include the
> implemented API with the implementation. The other is to strictly
> separate API from implementation.
> 
> My stance is somewhere in-between. Generally I prefer separating the API
> from the implementation, unless ...
> 
> For example, in Sling we have the Sling API bundle. This is IMHO a
> coherent API which is implemented by multiple bundles, e.g. the engine
> and the jcr/resource bundles. This API is separate.
> 
> On the other hand we have the exported API of the jcr/resource bundle.
> While we could separate it out into a separate bundle, the resulting
> bundle would be so small, that it probably makes no sense. In addition,
>  chances of another implementation of that API are close to zero.
> 
> For the compendium API, the case is that the Compendium library is a
> collection of more or less unrelated packages (there is close to no
> interpackage references on the API level). So having one Compendium
> bundle tends to lead to issues if we upgrade the implementations
> independetly of the versioning of the different packages.
> 
Yepp, exactly. That's why we either have to split up the compendium into
several api bundles (one for DS, one for config admin etc.) or the
implementations should bundle it.

It is a little bit strange that while OSGi is about modularity the
compendium is a single library :)

Carsten


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: OSGi Compendium

[Felix Meschberger <fm...@gmail.com>]

Carsten Ziegeler schrieb:
> Dominik Süß wrote:
>> Wouldn't it be more straight forward to exclude the Compendium Libraries
>> from the Declarative Services as well and have it as seperate bundle in
>> general?
>> I know this thoughts might lead to a big amount of small bundles and some
>> might not like this, but in this case I think it really would make sense.
> This actually would require to split up the compendium into the various
> parts and have an api bundle for each part.
> Updating the DS then would require to update the api and the impl bundle.
> 
> Hmm, not sure what the better option is. At least, it seems that pre
> bundling the compendium libs is wrong. So +1 to remove them from
> launchpad/base.
> 
> I like the way how the Apache Felix DS implementation does it. You get
> one bundle containing everything you need. So updating to a new spec
> version is pretty simply as the bundle is self contained.

Actually the Apache Felix DS implementation also exports the
Configuration Admin packages. This will probably be removed for the next
release.

> 
> How do other implementations do this?

AFAICT the Eclipse/Equinox project is using the approach of not
including the API in the implementation bundles but to have you install
the compendium library bundle.

There are basically two approaches to the question of where to locate
API with respect to the implementations: One is to include the
implemented API with the implementation. The other is to strictly
separate API from implementation.

My stance is somewhere in-between. Generally I prefer separating the API
from the implementation, unless ...

For example, in Sling we have the Sling API bundle. This is IMHO a
coherent API which is implemented by multiple bundles, e.g. the engine
and the jcr/resource bundles. This API is separate.

On the other hand we have the exported API of the jcr/resource bundle.
While we could separate it out into a separate bundle, the resulting
bundle would be so small, that it probably makes no sense. In addition,
 chances of another implementation of that API are close to zero.

For the compendium API, the case is that the Compendium library is a
collection of more or less unrelated packages (there is close to no
interpackage references on the API level). So having one Compendium
bundle tends to lead to issues if we upgrade the implementations
independetly of the versioning of the different packages.

As a result, in Apache Felix we export the respective API from the
implementation bundles. This also makes it easy to upgrade the API.

Regards
Felix


> 
> Carsten
>> Regards,
>> Dominik
>>
>> On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger <fm...@gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> Currently the Sling launcher (in the launchpad/base module) contains the
>>> Felix framework, the OSGi Core libraries as well as the OSGi Compendium
>>> libraries.
>>>
>>> While working on the implementation of the new Declarative Services 1.1
>>> features planned for addition in the OSGi Compendium Specification 4.2 I
>>> ran into a problem with this setup.
>>>
>>> Consider a bundle X importing the Declarative Services packages *before*
>>> the new implementation is installed. Both the system bundle (as per the
>>> launchpad/base module) and the Declarative Services implementation
>>> export version 1.0 of the org.osgi.service.component package. This
>>> results in all bundles wiring to the system bundle. Everything is fine.
>>>
>>> Now update the Declarative Services bundle which now exports version 1.1
>>> of the org.osgi.service.component package. The Declarative Services
>>> bundle binds to its own export using the latest version available.
>>> Bundle X is still wired to the system bundle because there is no
>>> rewiring taking place.
>>>
>>> The consequence is, that the new Declarative Services bundle cannot call
>>> any of the activate or deactivate methods of the components in Bundle X
>>> because the ComponentContext argument is not compatible.
>>>
>>> As a fix, I suggest we modify the launchpad/base bundle to *not* provide
>>> the Compendium packages any more. Instead we will expect that either the
>>> Compendium implementation bundles export the packages (as for example
>>> the Apache Felix Declarative Services bundle does) or that the
>>> compendium packages are installed as a bundle.
>>>
>>> WDYT ?
>>>
>>> Regards
>>> Felix
>>>
> 
> 

Re: OSGi Compendium

[Carsten Ziegeler <cz...@apache.org>]

Dominik Süß wrote:
> Wouldn't it be more straight forward to exclude the Compendium Libraries
> from the Declarative Services as well and have it as seperate bundle in
> general?
> I know this thoughts might lead to a big amount of small bundles and some
> might not like this, but in this case I think it really would make sense.
This actually would require to split up the compendium into the various
parts and have an api bundle for each part.
Updating the DS then would require to update the api and the impl bundle.

Hmm, not sure what the better option is. At least, it seems that pre
bundling the compendium libs is wrong. So +1 to remove them from
launchpad/base.

I like the way how the Apache Felix DS implementation does it. You get
one bundle containing everything you need. So updating to a new spec
version is pretty simply as the bundle is self contained.

How do other implementations do this?

Carsten
> 
> Regards,
> Dominik
> 
> On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger <fm...@gmail.com>wrote:
> 
>> Hi all,
>>
>> Currently the Sling launcher (in the launchpad/base module) contains the
>> Felix framework, the OSGi Core libraries as well as the OSGi Compendium
>> libraries.
>>
>> While working on the implementation of the new Declarative Services 1.1
>> features planned for addition in the OSGi Compendium Specification 4.2 I
>> ran into a problem with this setup.
>>
>> Consider a bundle X importing the Declarative Services packages *before*
>> the new implementation is installed. Both the system bundle (as per the
>> launchpad/base module) and the Declarative Services implementation
>> export version 1.0 of the org.osgi.service.component package. This
>> results in all bundles wiring to the system bundle. Everything is fine.
>>
>> Now update the Declarative Services bundle which now exports version 1.1
>> of the org.osgi.service.component package. The Declarative Services
>> bundle binds to its own export using the latest version available.
>> Bundle X is still wired to the system bundle because there is no
>> rewiring taking place.
>>
>> The consequence is, that the new Declarative Services bundle cannot call
>> any of the activate or deactivate methods of the components in Bundle X
>> because the ComponentContext argument is not compatible.
>>
>> As a fix, I suggest we modify the launchpad/base bundle to *not* provide
>> the Compendium packages any more. Instead we will expect that either the
>> Compendium implementation bundles export the packages (as for example
>> the Apache Felix Declarative Services bundle does) or that the
>> compendium packages are installed as a bundle.
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: OSGi Compendium

[Dominik Süß <do...@gmail.com>]

Wouldn't it be more straight forward to exclude the Compendium Libraries
from the Declarative Services as well and have it as seperate bundle in
general?
I know this thoughts might lead to a big amount of small bundles and some
might not like this, but in this case I think it really would make sense.

Regards,
Dominik

On Thu, Jun 25, 2009 at 4:39 PM, Felix Meschberger <fm...@gmail.com>wrote:

> Hi all,
>
> Currently the Sling launcher (in the launchpad/base module) contains the
> Felix framework, the OSGi Core libraries as well as the OSGi Compendium
> libraries.
>
> While working on the implementation of the new Declarative Services 1.1
> features planned for addition in the OSGi Compendium Specification 4.2 I
> ran into a problem with this setup.
>
> Consider a bundle X importing the Declarative Services packages *before*
> the new implementation is installed. Both the system bundle (as per the
> launchpad/base module) and the Declarative Services implementation
> export version 1.0 of the org.osgi.service.component package. This
> results in all bundles wiring to the system bundle. Everything is fine.
>
> Now update the Declarative Services bundle which now exports version 1.1
> of the org.osgi.service.component package. The Declarative Services
> bundle binds to its own export using the latest version available.
> Bundle X is still wired to the system bundle because there is no
> rewiring taking place.
>
> The consequence is, that the new Declarative Services bundle cannot call
> any of the activate or deactivate methods of the components in Bundle X
> because the ComponentContext argument is not compatible.
>
> As a fix, I suggest we modify the launchpad/base bundle to *not* provide
> the Compendium packages any more. Instead we will expect that either the
> Compendium implementation bundles export the packages (as for example
> the Apache Felix Declarative Services bundle does) or that the
> compendium packages are installed as a bundle.
>
> WDYT ?
>
> Regards
> Felix
>