felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hall <he...@ungoverned.org>
Subject Re: Core and Compendium APIS at runtime
Date Wed, 20 May 2015 13:56:41 GMT
On 5/20/15 05:15 , Milen Dyankov wrote:

>
> Thanks for your answer Richard!
>
> I am aware if the FAQ however what it basically tells you is "it depends"
> ;) Thus I was hoping for some more insides so I can better understand the
> intentions and the situation with service APIs from OSGi specs as of
today.
> So, if I understand your answer correctly the conclusions are:
>
> - Never use compendium bundle at runtime because it is not a proper bundle
> (whatever that means).


Bundles (i.e., modules) are supposed to be cohesive and loosely coupled.
The compendium is just a bunch of APIs thrown into a JAR file, so that
hardly is cohesive and certainly wouldn't lead to low coupling. Understand?

>  I agree with you that this should be in FAQ at
> least. It would be even better if there is some more official statement
> (may be there is and I just couldn't find it) that also explains why!
>
> - There are no proper/official separate API bundles for the service APIs
> defined in the specs. Vendors are free to choose if they (1) package the
> API in the implementation bundle, (2) provide the implementation only or
> (3) provide separate bundles for API and implementation. Felix has chosen
> the first approach to avoid maintaining too many bundles.


No choice has been made at Apache Felix

>
>  IMHO
> and according to the FAQ it seems the third approach makes more sense:
"*This
> situation would be different if the service API were package in a separate
> bundle. In this situation, all consumer bundles would be wired to the API
> bundle, not to the provider bundle. Thus, if the provider were updated or
> uninstalled and then refreshed, the consumer bundles would only be
> minimally impacted (i.e., they would either switch to the new version of
> the provider or to a different provider).*"  but I respect your decisions.
>
> - There is no issue with split packages
> <http://wiki.osgi.org/wiki/Split_Packages>
<http://wiki.osgi.org/wiki/Split_Packages> because regardless of the
> provider and the way APIs they are packaged/exported the API package(s)
> *should* always be both complete and limited to what what OSGi alliance
has
> specified. IMHO this should be a bit more strict than just expecting
> vendors to "do it right". Then perhaps consumers can feel a bit more safe
> from such issues when choosing an implementation (without the need to
> examine it's internals). But I'm not going to argue about it.
>
> Once again thanks for your answers. Please correct me if
> I misunderstood something.
>
> Regards,
> Milen
>
>
>
>
>
> On Sun, May 17, 2015 at 8:01 PM, Richard S. Hall <heavy@ungoverned.org>
<heavy@ungoverned.org>
> wrote:
>

>> On 5/17/15 12:57 , Milen Dyankov wrote:
>>

 >>> Hi,
>>>
>>> I recently stumbled upon something that makes me wonder about OSGI specs
>>> APIs. As Metatype was the one API that made me start thinking about the
>>> issue, I'll use it as an example but the question is about APIs in
>>> general.
>>>
>>> So while attempting to replace Felix's Metatype with Equinox one,  I
>>> realized Felix implementation jar provides also the API while Equinox
does
>>> not. So my first thought was that there should be another jar with the
API
>>> alone but I couldn't find one. Second thought was to install
osgi.cmpn.jar
>>> (it's  a bundle after all) but I was told I should never do that and
that
>>> those jars are provided to be only used as compile time dependencies.
>>>
>>> So here comes the question - who should provide the APIs at runtime for
a
>>> OSGI specs?
>>>

 >>
>> See the FAQ:
>>
>>
>>
http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages
<http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html#should-a-service-providerconsumer-bundle-be-packaged-with-its-service-api-packages>
>>
>>  I would actually split the question into a few:

 >>>
>>> - is it really forbidden/nor recommended to use osgi.cmpn.jar at
runtime?
>>> If so can someone please elaborate?
>>>

 >>
>> This should probably be in the FAQ too. The compendium only happens to be
>> packaged as a bundle because that is how it is built, not because it
>> actually is a proper bundle. It is not cohesive, since it is just a
>> collection of API, and pulls in unnecessary dependencies. The OSGi
Alliance
>> should probably quit publishing it as a bundle. Over the years, we seen
>> lots of users run into difficulties when using it as a bundle.
>>
>>  - shouldn't there be independent  (perhaps released by OSGI alliance)
API

 >>>
>>> bundles? If there should be but they are missing at the moment then why
>>> Felix does not provide APIs in a separate bundles instead of packaging
>>> them
>>> with the implementation?
>>>

 >>
>> It's not really the purpose of the OSGi Alliance, but I suppose they
>> could. At Apache Felix, we have enough bundles to maintain, without
>> creating more.
>>
>>  - finally if the expectation is that each implementation provides also
the

 >>>
>>> API isn't this leading to split package condition? I'm aware for most
>>> specs
>>> it probably makes no sense to have 2 different implementations at the
same
>>> time but still ...
>>>

 >>
>> No. How would they be split? Packages are self contained in OSGi bundles
>> unless you explicitly make them split. If done properly, there is little
>> harm in having multiple providers of a package. However, having a single
>> provider does provide some benefits too. As the FAQ says, it just depends
>> on your situation.
>>
>> If you really are dealing with composing a system out of third-party
>> bundles, though, you cannot really always have it your way so you have to
>> deal with the realities on the ground.
>>
>> -> richard
>>
>>

 >>> I would appreciate if someone can throw more light on the subject.
>>>
>>> Regards,
>>> Milen
>>>
>>>

 >>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>

 >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message