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