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-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > >
