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