You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Milen Dyankov <mi...@gmail.com> on 2015/05/17 18:57:47 UTC
Core and Compendium APIS at runtime
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?
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?
- 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?
- 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 ...
I would appreciate if someone can throw more light on the subject.
Regards,
Milen
Re: Core and Compendium APIS at runtime
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/20/15 14:42 , Milen Dyankov wrote:
>> Now, if you are saying that the framework should somehow enforce that
>> implementations never provide the service API and that only the "official"
>> service API bundles can be used to provide those packages, then I'd say
>> that this would go too far.
>
> No I didn't meant to say that. Rather that implementations would not
> have/need to do it. At least I for one can not see a good reason why would
> someone want to provide the same version of someone else's API if
> it's already publicly available.
Well, that's the point, they make this decision based on their own
requirements. Some people might want their bundle to be self-contained
to make it easier to use or want to limit third-party dependencies, etc.
It just depends. :-)
-> richard
>
>
>
> On Wed, May 20, 2015 at 5:47 PM, Richard S. Hall <he...@ungoverned.org>
> wrote:
>
>> On 5/20/15 11:37 , Milen Dyankov wrote:
>>
>>> Well I agree in general. My only point is that IMHO the one defining the
>>> API should also be the one providing it at runtime. Since OSGi alliance is
>>> defining a spec which describes a service API it should be the one
>>> providing the API bundle.
>>>
>> And apparently the OSGi Alliance will do so from now on; however, ...
>>
>> Vendors are still free to provide their own
>>> implementations and extensions anyway they wish. But this way a random
>>> consumer does not have to investigate if given vendor has included the API
>>> in the implementation and if not then worry about which bundles need to be
>>> installed at runtime to satisfy imports.
>>>
>> You will still not be relieved of performing this task since bundles may
>> or may not come packaged with the APIs, so you'll still likely need to
>> understand this, because multiple providers can (and do) lead to unexpected
>> wiring when you are assuming there is only one provider.
>>
>> Now, if you are saying that the framework should somehow enforce that
>> implementations never provide the service API and that only the "official"
>> service API bundles can be used to provide those packages, then I'd say
>> that this would go too far.
>>
>> I personally (as probably most
>>> people on this list) can deal with it. And from that perspective it's easy
>>> (and partly true) to say it's not rally a problem. However it doesn't look
>>> nice and it does not help to fight the "too complex" and "too messy"
>>> stereotypes.
>>> Just my 2 cents!
>>>
>> Understood, but clamping things downs just leads to other messiness (see
>> .NET and its strong versions).
>>
>> As I said before, there is no free lunch. Developing software is
>> complicated and you have to work hard to keep it from getting messy.
>>
>> -> richard
>>
>>
>>
>>> Best,
>>> Milen
>>>
>>>
>>> On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>>
>>> 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"
>>>>> ;)
>>>>>
>>>>> Unfortunately, it does depend on your circumstances. There are very few
>>>> cases in software engineering where you can say, "always do it like
>>>> this"...that's the way the cookie crumbles.
>>>>
>>>> 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, but generally people have
>>>> gravitated to that approach. Subprojects are free to do it any way they
>>>> want, because use cases vary.
>>>>
>>>> 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.
>>>>>
>>>>> It does make a lot of sense in many cases. If you are unsure of your
>>>> needs, I'd recommend this as the default approach.
>>>>
>>>>
>>>> - There is no issue with 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.
>>>>>
>>>>> There is not much that can be done about this. What do you want the
>>>> OSGi
>>>> Alliance to do? We could require that ever developer give a signed list
>>>> of
>>>> every class that should be in every package and store that in some
>>>> central
>>>> repository. Then any time a bundle says they export a particular class,
>>>> the
>>>> framework could go out to that authority get the list of classes for that
>>>> package and scan the bundle to make sure it contains the proper classes.
>>>> Of
>>>> course, this wouldn't even guarantee anything, since the bundle could
>>>> include bogus implementation classes. Nor could you make it better by
>>>> including class signatures in this central repository, because that would
>>>> eliminate substitutability of different provider implementations.
>>>>
>>>> At some point, you just have to trust the bundle developers and if they
>>>> end up lying, the you put that bundle developer on your blacklist and you
>>>> exclude them in your future choices.
>>>>
>>>> As with everything, you're not going to get something (worthwhile) for
>>>> free.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>> 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<he...@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
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Core and Compendium APIS at runtime
Posted by Milen Dyankov <mi...@gmail.com>.
>
> Now, if you are saying that the framework should somehow enforce that
> implementations never provide the service API and that only the "official"
> service API bundles can be used to provide those packages, then I'd say
> that this would go too far.
No I didn't meant to say that. Rather that implementations would not
have/need to do it. At least I for one can not see a good reason why would
someone want to provide the same version of someone else's API if
it's already publicly available.
On Wed, May 20, 2015 at 5:47 PM, Richard S. Hall <he...@ungoverned.org>
wrote:
> On 5/20/15 11:37 , Milen Dyankov wrote:
>
>> Well I agree in general. My only point is that IMHO the one defining the
>> API should also be the one providing it at runtime. Since OSGi alliance is
>> defining a spec which describes a service API it should be the one
>> providing the API bundle.
>>
>
> And apparently the OSGi Alliance will do so from now on; however, ...
>
> Vendors are still free to provide their own
>> implementations and extensions anyway they wish. But this way a random
>> consumer does not have to investigate if given vendor has included the API
>> in the implementation and if not then worry about which bundles need to be
>> installed at runtime to satisfy imports.
>>
>
> You will still not be relieved of performing this task since bundles may
> or may not come packaged with the APIs, so you'll still likely need to
> understand this, because multiple providers can (and do) lead to unexpected
> wiring when you are assuming there is only one provider.
>
> Now, if you are saying that the framework should somehow enforce that
> implementations never provide the service API and that only the "official"
> service API bundles can be used to provide those packages, then I'd say
> that this would go too far.
>
> I personally (as probably most
>> people on this list) can deal with it. And from that perspective it's easy
>> (and partly true) to say it's not rally a problem. However it doesn't look
>> nice and it does not help to fight the "too complex" and "too messy"
>> stereotypes.
>> Just my 2 cents!
>>
>
> Understood, but clamping things downs just leads to other messiness (see
> .NET and its strong versions).
>
> As I said before, there is no free lunch. Developing software is
> complicated and you have to work hard to keep it from getting messy.
>
> -> richard
>
>
>
>> Best,
>> Milen
>>
>>
>> On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>>
>> 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"
>>>> ;)
>>>>
>>>> Unfortunately, it does depend on your circumstances. There are very few
>>> cases in software engineering where you can say, "always do it like
>>> this"...that's the way the cookie crumbles.
>>>
>>> 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, but generally people have
>>> gravitated to that approach. Subprojects are free to do it any way they
>>> want, because use cases vary.
>>>
>>> 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.
>>>>
>>>> It does make a lot of sense in many cases. If you are unsure of your
>>> needs, I'd recommend this as the default approach.
>>>
>>>
>>> - There is no issue with 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.
>>>>
>>>> There is not much that can be done about this. What do you want the
>>> OSGi
>>> Alliance to do? We could require that ever developer give a signed list
>>> of
>>> every class that should be in every package and store that in some
>>> central
>>> repository. Then any time a bundle says they export a particular class,
>>> the
>>> framework could go out to that authority get the list of classes for that
>>> package and scan the bundle to make sure it contains the proper classes.
>>> Of
>>> course, this wouldn't even guarantee anything, since the bundle could
>>> include bogus implementation classes. Nor could you make it better by
>>> including class signatures in this central repository, because that would
>>> eliminate substitutability of different provider implementations.
>>>
>>> At some point, you just have to trust the bundle developers and if they
>>> end up lying, the you put that bundle developer on your blacklist and you
>>> exclude them in your future choices.
>>>
>>> As with everything, you're not going to get something (worthwhile) for
>>> free.
>>>
>>> -> richard
>>>
>>>
>>>
>>> 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<he...@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
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
http://about.me/milen
Re: Core and Compendium APIS at runtime
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 5/20/15 11:37 , Milen Dyankov wrote:
> Well I agree in general. My only point is that IMHO the one defining the
> API should also be the one providing it at runtime. Since OSGi alliance is
> defining a spec which describes a service API it should be the one
> providing the API bundle.
And apparently the OSGi Alliance will do so from now on; however, ...
> Vendors are still free to provide their own
> implementations and extensions anyway they wish. But this way a random
> consumer does not have to investigate if given vendor has included the API
> in the implementation and if not then worry about which bundles need to be
> installed at runtime to satisfy imports.
You will still not be relieved of performing this task since bundles may
or may not come packaged with the APIs, so you'll still likely need to
understand this, because multiple providers can (and do) lead to
unexpected wiring when you are assuming there is only one provider.
Now, if you are saying that the framework should somehow enforce that
implementations never provide the service API and that only the
"official" service API bundles can be used to provide those packages,
then I'd say that this would go too far.
> I personally (as probably most
> people on this list) can deal with it. And from that perspective it's easy
> (and partly true) to say it's not rally a problem. However it doesn't look
> nice and it does not help to fight the "too complex" and "too messy"
> stereotypes.
> Just my 2 cents!
Understood, but clamping things downs just leads to other messiness (see
.NET and its strong versions).
As I said before, there is no free lunch. Developing software is
complicated and you have to work hard to keep it from getting messy.
-> richard
>
> Best,
> Milen
>
>
> On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
> wrote:
>
>> 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"
>>> ;)
>>>
>> Unfortunately, it does depend on your circumstances. There are very few
>> cases in software engineering where you can say, "always do it like
>> this"...that's the way the cookie crumbles.
>>
>> 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, but generally people have
>> gravitated to that approach. Subprojects are free to do it any way they
>> want, because use cases vary.
>>
>> 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.
>>>
>> It does make a lot of sense in many cases. If you are unsure of your
>> needs, I'd recommend this as the default approach.
>>
>>
>>> - There is no issue with 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.
>>>
>> There is not much that can be done about this. What do you want the OSGi
>> Alliance to do? We could require that ever developer give a signed list of
>> every class that should be in every package and store that in some central
>> repository. Then any time a bundle says they export a particular class, the
>> framework could go out to that authority get the list of classes for that
>> package and scan the bundle to make sure it contains the proper classes. Of
>> course, this wouldn't even guarantee anything, since the bundle could
>> include bogus implementation classes. Nor could you make it better by
>> including class signatures in this central repository, because that would
>> eliminate substitutability of different provider implementations.
>>
>> At some point, you just have to trust the bundle developers and if they
>> end up lying, the you put that bundle developer on your blacklist and you
>> exclude them in your future choices.
>>
>> As with everything, you're not going to get something (worthwhile) for
>> free.
>>
>> -> richard
>>
>>
>>
>>> 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<he...@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
>>>>
>>>> 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
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Core and Compendium APIS at runtime
Posted by Raymond Auge <ra...@liferay.com>.
Is RSA a special case then?
- Ray
On Mon, May 25, 2015 at 9:50 AM, Richard S. Hall <he...@ungoverned.org>
wrote:
> Overall, I agree...we should probably add some of this argumentation to
> our FAQ entry...
>
> -> richard
>
>
> On 5/25/15 03:38 , Peter Kriens wrote:
>
>> This kind of reasoning is often caused by not seeing the extremely tight
>> relation between the provider of an API and that API itself. There is
>> virtually no backward compatibility for providers, if the API changes, you
>> need a new provider. Separating the provider from its API therefore just
>> creates a lot of work and potential error cases that provide no benefit
>> whatsoever.
>>
>> The best practice I learned over time is therefore is that a provider
>> includes an exact copy of the API package that it is build against and both
>> exports AND imports it. Since OSGi packages have a globally unique name +
>> version this works, the framework will share one of the exported packages
>> if possible. This model has a number of advantages:
>>
>> 1) The resolver can automatically drag in implementations based on the API
>> 2) You have significantly fewer bundles to worry about
>> 3) You always have the right version at hand
>> 4) bnd supports this model very well with its package include from class
>> path function and calculation of importing exports.
>>
>> Every time I run into bundles that do not include their API I get this
>> desperate sinking feeling :-(
>>
>> The idea that it works better with multiple providers of the same API is
>> nonsense since they both MUST use the identical versions of the overlapping
>> packages. That is, there is no backward compatibility to speak of for
>> providers. So substitutable imports work fine for this use case.
>>
>> The only argument for separating API and implementation in two bundles is
>> that you do not have to refresh the client if you update an implementation.
>> True, but due to transitive dependencies it takes real hard work to
>> actually achieve this unless you have a small trivial system. And an OSGi
>> system that can handle the going down of any bundle is likely not very
>> valuable since it will likely fail. So realistically, this argument sounds
>> nice in theory but has very little value in practice.
>>
>> Interestingly, this discussion was held early on and several times
>> thereafter. Initially, I was not sure, the separate API bundle did not
>> sound so bad. Now, 15 years later I am quite convinced that the provider
>> including the API is the best solution in most cases.
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> On 20 mei 2015, at 17:37, Milen Dyankov <mi...@gmail.com> wrote:
>>>
>>> Well I agree in general. My only point is that IMHO the one defining the
>>> API should also be the one providing it at runtime. Since OSGi alliance
>>> is
>>> defining a spec which describes a service API it should be the one
>>> providing the API bundle. Vendors are still free to provide their own
>>> implementations and extensions anyway they wish. But this way a random
>>> consumer does not have to investigate if given vendor has included the
>>> API
>>> in the implementation and if not then worry about which bundles need to
>>> be
>>> installed at runtime to satisfy imports. I personally (as probably most
>>> people on this list) can deal with it. And from that perspective it's
>>> easy
>>> (and partly true) to say it's not rally a problem. However it doesn't
>>> look
>>> nice and it does not help to fight the "too complex" and "too messy"
>>> stereotypes.
>>> Just my 2 cents!
>>>
>>> Best,
>>> Milen
>>>
>>>
>>> On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>>
>>> 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"
>>>>> ;)
>>>>>
>>>>> Unfortunately, it does depend on your circumstances. There are very
>>>> few
>>>> cases in software engineering where you can say, "always do it like
>>>> this"...that's the way the cookie crumbles.
>>>>
>>>> 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, but generally people have
>>>> gravitated to that approach. Subprojects are free to do it any way they
>>>> want, because use cases vary.
>>>>
>>>> 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.
>>>>>
>>>>> It does make a lot of sense in many cases. If you are unsure of your
>>>> needs, I'd recommend this as the default approach.
>>>>
>>>>
>>>> - There is no issue with 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.
>>>>>
>>>>> There is not much that can be done about this. What do you want the
>>>> OSGi
>>>> Alliance to do? We could require that ever developer give a signed list
>>>> of
>>>> every class that should be in every package and store that in some
>>>> central
>>>> repository. Then any time a bundle says they export a particular class,
>>>> the
>>>> framework could go out to that authority get the list of classes for
>>>> that
>>>> package and scan the bundle to make sure it contains the proper
>>>> classes. Of
>>>> course, this wouldn't even guarantee anything, since the bundle could
>>>> include bogus implementation classes. Nor could you make it better by
>>>> including class signatures in this central repository, because that
>>>> would
>>>> eliminate substitutability of different provider implementations.
>>>>
>>>> At some point, you just have to trust the bundle developers and if they
>>>> end up lying, the you put that bundle developer on your blacklist and
>>>> you
>>>> exclude them in your future choices.
>>>>
>>>> As with everything, you're not going to get something (worthwhile) for
>>>> free.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>> 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<he...@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
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>> --
>>> http://about.me/milen
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Core and Compendium APIS at runtime
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Overall, I agree...we should probably add some of this argumentation to
our FAQ entry...
-> richard
On 5/25/15 03:38 , Peter Kriens wrote:
> This kind of reasoning is often caused by not seeing the extremely tight relation between the provider of an API and that API itself. There is virtually no backward compatibility for providers, if the API changes, you need a new provider. Separating the provider from its API therefore just creates a lot of work and potential error cases that provide no benefit whatsoever.
>
> The best practice I learned over time is therefore is that a provider includes an exact copy of the API package that it is build against and both exports AND imports it. Since OSGi packages have a globally unique name + version this works, the framework will share one of the exported packages if possible. This model has a number of advantages:
>
> 1) The resolver can automatically drag in implementations based on the API
> 2) You have significantly fewer bundles to worry about
> 3) You always have the right version at hand
> 4) bnd supports this model very well with its package include from class path function and calculation of importing exports.
>
> Every time I run into bundles that do not include their API I get this desperate sinking feeling :-(
>
> The idea that it works better with multiple providers of the same API is nonsense since they both MUST use the identical versions of the overlapping packages. That is, there is no backward compatibility to speak of for providers. So substitutable imports work fine for this use case.
>
> The only argument for separating API and implementation in two bundles is that you do not have to refresh the client if you update an implementation. True, but due to transitive dependencies it takes real hard work to actually achieve this unless you have a small trivial system. And an OSGi system that can handle the going down of any bundle is likely not very valuable since it will likely fail. So realistically, this argument sounds nice in theory but has very little value in practice.
>
> Interestingly, this discussion was held early on and several times thereafter. Initially, I was not sure, the separate API bundle did not sound so bad. Now, 15 years later I am quite convinced that the provider including the API is the best solution in most cases.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>> On 20 mei 2015, at 17:37, Milen Dyankov <mi...@gmail.com> wrote:
>>
>> Well I agree in general. My only point is that IMHO the one defining the
>> API should also be the one providing it at runtime. Since OSGi alliance is
>> defining a spec which describes a service API it should be the one
>> providing the API bundle. Vendors are still free to provide their own
>> implementations and extensions anyway they wish. But this way a random
>> consumer does not have to investigate if given vendor has included the API
>> in the implementation and if not then worry about which bundles need to be
>> installed at runtime to satisfy imports. I personally (as probably most
>> people on this list) can deal with it. And from that perspective it's easy
>> (and partly true) to say it's not rally a problem. However it doesn't look
>> nice and it does not help to fight the "too complex" and "too messy"
>> stereotypes.
>> Just my 2 cents!
>>
>> Best,
>> Milen
>>
>>
>> On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>>
>>> 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"
>>>> ;)
>>>>
>>> Unfortunately, it does depend on your circumstances. There are very few
>>> cases in software engineering where you can say, "always do it like
>>> this"...that's the way the cookie crumbles.
>>>
>>> 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, but generally people have
>>> gravitated to that approach. Subprojects are free to do it any way they
>>> want, because use cases vary.
>>>
>>> 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.
>>>>
>>> It does make a lot of sense in many cases. If you are unsure of your
>>> needs, I'd recommend this as the default approach.
>>>
>>>
>>>> - There is no issue with 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.
>>>>
>>> There is not much that can be done about this. What do you want the OSGi
>>> Alliance to do? We could require that ever developer give a signed list of
>>> every class that should be in every package and store that in some central
>>> repository. Then any time a bundle says they export a particular class, the
>>> framework could go out to that authority get the list of classes for that
>>> package and scan the bundle to make sure it contains the proper classes. Of
>>> course, this wouldn't even guarantee anything, since the bundle could
>>> include bogus implementation classes. Nor could you make it better by
>>> including class signatures in this central repository, because that would
>>> eliminate substitutability of different provider implementations.
>>>
>>> At some point, you just have to trust the bundle developers and if they
>>> end up lying, the you put that bundle developer on your blacklist and you
>>> exclude them in your future choices.
>>>
>>> As with everything, you're not going to get something (worthwhile) for
>>> free.
>>>
>>> -> richard
>>>
>>>
>>>
>>>> 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<he...@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
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> --
>> http://about.me/milen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Core and Compendium APIS at runtime
Posted by Christian Schneider <ch...@die-schneider.net>.
Do you also have best practices for clients?
I think in most cases it makes sense that a client just imports a the
spec package.
What about the case where a client optionally depends on a spec package?
One case I saw several times was an optional dependency on the event
admin. The problem with this is that if the provider of the package is
not present when the bundle installs it will not see it. Karaf 4 will
provide a mechanism to rewire a bundle with optional packages once they
are resolveable but this also can lead to cascades of restarts.
So does it make sense for the case of clients with an optional
dependency on an API package to embed and import/export it?
One thing that could go wrong with this is that client and provider of
the API might bind to different versions of the package. So I am not sure.
One such case where we currently discuss about this is:
https://issues.apache.org/jira/browse/KARAF-3739
Christian
Am 25.05.2015 um 09:38 schrieb Peter Kriens:
> This kind of reasoning is often caused by not seeing the extremely tight relation between the provider of an API and that API itself. There is virtually no backward compatibility for providers, if the API changes, you need a new provider. Separating the provider from its API therefore just creates a lot of work and potential error cases that provide no benefit whatsoever.
>
> The best practice I learned over time is therefore is that a provider includes an exact copy of the API package that it is build against and both exports AND imports it. Since OSGi packages have a globally unique name + version this works, the framework will share one of the exported packages if possible. This model has a number of advantages:
>
> 1) The resolver can automatically drag in implementations based on the API
> 2) You have significantly fewer bundles to worry about
> 3) You always have the right version at hand
> 4) bnd supports this model very well with its package include from class path function and calculation of importing exports.
>
> Every time I run into bundles that do not include their API I get this desperate sinking feeling :-(
>
> The idea that it works better with multiple providers of the same API is nonsense since they both MUST use the identical versions of the overlapping packages. That is, there is no backward compatibility to speak of for providers. So substitutable imports work fine for this use case.
>
> The only argument for separating API and implementation in two bundles is that you do not have to refresh the client if you update an implementation. True, but due to transitive dependencies it takes real hard work to actually achieve this unless you have a small trivial system. And an OSGi system that can handle the going down of any bundle is likely not very valuable since it will likely fail. So realistically, this argument sounds nice in theory but has very little value in practice.
>
> Interestingly, this discussion was held early on and several times thereafter. Initially, I was not sure, the separate API bundle did not sound so bad. Now, 15 years later I am quite convinced that the provider including the API is the best solution in most cases.
>
> Kind regards,
>
> Peter Kriens
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Core and Compendium APIS at runtime
Posted by Peter Kriens <pk...@gmail.com>.
This kind of reasoning is often caused by not seeing the extremely tight relation between the provider of an API and that API itself. There is virtually no backward compatibility for providers, if the API changes, you need a new provider. Separating the provider from its API therefore just creates a lot of work and potential error cases that provide no benefit whatsoever.
The best practice I learned over time is therefore is that a provider includes an exact copy of the API package that it is build against and both exports AND imports it. Since OSGi packages have a globally unique name + version this works, the framework will share one of the exported packages if possible. This model has a number of advantages:
1) The resolver can automatically drag in implementations based on the API
2) You have significantly fewer bundles to worry about
3) You always have the right version at hand
4) bnd supports this model very well with its package include from class path function and calculation of importing exports.
Every time I run into bundles that do not include their API I get this desperate sinking feeling :-(
The idea that it works better with multiple providers of the same API is nonsense since they both MUST use the identical versions of the overlapping packages. That is, there is no backward compatibility to speak of for providers. So substitutable imports work fine for this use case.
The only argument for separating API and implementation in two bundles is that you do not have to refresh the client if you update an implementation. True, but due to transitive dependencies it takes real hard work to actually achieve this unless you have a small trivial system. And an OSGi system that can handle the going down of any bundle is likely not very valuable since it will likely fail. So realistically, this argument sounds nice in theory but has very little value in practice.
Interestingly, this discussion was held early on and several times thereafter. Initially, I was not sure, the separate API bundle did not sound so bad. Now, 15 years later I am quite convinced that the provider including the API is the best solution in most cases.
Kind regards,
Peter Kriens
> On 20 mei 2015, at 17:37, Milen Dyankov <mi...@gmail.com> wrote:
>
> Well I agree in general. My only point is that IMHO the one defining the
> API should also be the one providing it at runtime. Since OSGi alliance is
> defining a spec which describes a service API it should be the one
> providing the API bundle. Vendors are still free to provide their own
> implementations and extensions anyway they wish. But this way a random
> consumer does not have to investigate if given vendor has included the API
> in the implementation and if not then worry about which bundles need to be
> installed at runtime to satisfy imports. I personally (as probably most
> people on this list) can deal with it. And from that perspective it's easy
> (and partly true) to say it's not rally a problem. However it doesn't look
> nice and it does not help to fight the "too complex" and "too messy"
> stereotypes.
> Just my 2 cents!
>
> Best,
> Milen
>
>
> On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
> wrote:
>
>>
>> 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"
>>> ;)
>>>
>>
>> Unfortunately, it does depend on your circumstances. There are very few
>> cases in software engineering where you can say, "always do it like
>> this"...that's the way the cookie crumbles.
>>
>> 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, but generally people have
>> gravitated to that approach. Subprojects are free to do it any way they
>> want, because use cases vary.
>>
>> 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.
>>>
>>
>> It does make a lot of sense in many cases. If you are unsure of your
>> needs, I'd recommend this as the default approach.
>>
>>
>>> - There is no issue with 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.
>>>
>>
>> There is not much that can be done about this. What do you want the OSGi
>> Alliance to do? We could require that ever developer give a signed list of
>> every class that should be in every package and store that in some central
>> repository. Then any time a bundle says they export a particular class, the
>> framework could go out to that authority get the list of classes for that
>> package and scan the bundle to make sure it contains the proper classes. Of
>> course, this wouldn't even guarantee anything, since the bundle could
>> include bogus implementation classes. Nor could you make it better by
>> including class signatures in this central repository, because that would
>> eliminate substitutability of different provider implementations.
>>
>> At some point, you just have to trust the bundle developers and if they
>> end up lying, the you put that bundle developer on your blacklist and you
>> exclude them in your future choices.
>>
>> As with everything, you're not going to get something (worthwhile) for
>> free.
>>
>> -> richard
>>
>>
>>
>>> 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<he...@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
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> http://about.me/milen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Core and Compendium APIS at runtime
Posted by Milen Dyankov <mi...@gmail.com>.
Well I agree in general. My only point is that IMHO the one defining the
API should also be the one providing it at runtime. Since OSGi alliance is
defining a spec which describes a service API it should be the one
providing the API bundle. Vendors are still free to provide their own
implementations and extensions anyway they wish. But this way a random
consumer does not have to investigate if given vendor has included the API
in the implementation and if not then worry about which bundles need to be
installed at runtime to satisfy imports. I personally (as probably most
people on this list) can deal with it. And from that perspective it's easy
(and partly true) to say it's not rally a problem. However it doesn't look
nice and it does not help to fight the "too complex" and "too messy"
stereotypes.
Just my 2 cents!
Best,
Milen
On Wed, May 20, 2015 at 3:55 PM, Richard S. Hall <he...@ungoverned.org>
wrote:
>
> 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"
>> ;)
>>
>
> Unfortunately, it does depend on your circumstances. There are very few
> cases in software engineering where you can say, "always do it like
> this"...that's the way the cookie crumbles.
>
> 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, but generally people have
> gravitated to that approach. Subprojects are free to do it any way they
> want, because use cases vary.
>
> 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.
>>
>
> It does make a lot of sense in many cases. If you are unsure of your
> needs, I'd recommend this as the default approach.
>
>
>> - There is no issue with 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.
>>
>
> There is not much that can be done about this. What do you want the OSGi
> Alliance to do? We could require that ever developer give a signed list of
> every class that should be in every package and store that in some central
> repository. Then any time a bundle says they export a particular class, the
> framework could go out to that authority get the list of classes for that
> package and scan the bundle to make sure it contains the proper classes. Of
> course, this wouldn't even guarantee anything, since the bundle could
> include bogus implementation classes. Nor could you make it better by
> including class signatures in this central repository, because that would
> eliminate substitutability of different provider implementations.
>
> At some point, you just have to trust the bundle developers and if they
> end up lying, the you put that bundle developer on your blacklist and you
> exclude them in your future choices.
>
> As with everything, you're not going to get something (worthwhile) for
> free.
>
> -> richard
>
>
>
>> 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<he...@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
>>>
>>> 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
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
http://about.me/milen
Re: Core and Compendium APIS at runtime
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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"
> ;)
Unfortunately, it does depend on your circumstances. There are very few
cases in software engineering where you can say, "always do it like
this"...that's the way the cookie crumbles.
> 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, but generally people have
gravitated to that approach. Subprojects are free to do it any way they
want, because use cases vary.
> 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.
It does make a lot of sense in many cases. If you are unsure of your
needs, I'd recommend this as the default approach.
>
> - There is no issue with 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.
There is not much that can be done about this. What do you want the OSGi
Alliance to do? We could require that ever developer give a signed list
of every class that should be in every package and store that in some
central repository. Then any time a bundle says they export a particular
class, the framework could go out to that authority get the list of
classes for that package and scan the bundle to make sure it contains
the proper classes. Of course, this wouldn't even guarantee anything,
since the bundle could include bogus implementation classes. Nor could
you make it better by including class signatures in this central
repository, because that would eliminate substitutability of different
provider implementations.
At some point, you just have to trust the bundle developers and if they
end up lying, the you put that bundle developer on your blacklist and
you exclude them in your future choices.
As with everything, you're not going to get something (worthwhile) for free.
-> richard
>
> 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<he...@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
>>
>> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Core and Compendium APIS at runtime
Posted by Raymond Auge <ra...@liferay.com>.
A little bit of good news on this topic.
For R6 you will find that the OSGi Alliance will release (including to
Maven Central) complete (code, source, javadoc, pom), individually
packaged, usable at runtime, companion code bundles for every single spec
(including everything not modified during this last development cycle, i.e.
every latest version of every spec).
I hope that with this the question about the super companion code bundles
will be much less of an issue.
Everyone will be encouraged to (and will likely gravitate toward) use these
new bundles! :)
You can thank BJ Hargrave and the BND team (mostly BJ) for all the hard
work they did to make that possible, particular w.r.t. the maven stuff ;)
Sincerely,
- Ray
On Wed, May 20, 2015 at 9:56 AM, Richard Hall <he...@ungoverned.org> wrote:
> 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 <he...@ungoverned.org>
> <he...@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
> >>
> >>
>
> >
> >
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Core and Compendium APIS at runtime
Posted by Richard Hall <he...@ungoverned.org>.
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 <he...@ungoverned.org>
<he...@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
>>
>>
>
>
Re: Core and Compendium APIS at runtime
Posted by Milen Dyankov <mi...@gmail.com>.
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). 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. 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> 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 <he...@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
>
> 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
>
>
--
http://about.me/milen
Re: Core and Compendium APIS at runtime
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
> 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