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
