For those not following the users@ discussion, here is a link:
http://www.nabble.com/-karaf--Equinox-integration-problem---and-possible-solution-to23559788.html
The above thread discusses an issue with using our compendium bundle.
This is not the first time this issue has been raised. The summary is
our compendium bundle results in odd class loading errors in some cases.
My conclusion is that this is because we dynamically import *, so
dependent bundles are using the compendium packages even though the
compendium dependencies are not actually satisfied.
We dynamically import * to avoid forcing all users of compendium to
satisfy all dependencies to use it, because most of the time they are
not needed for the contained service interfaces. However, in the cases
where they are needed, it is problematic.
Why do we provide these bundles at all? Originally, the OSGi JAR files
were not bundles, so we needed something and did it ourselves. Now this
is no longer the case, I believe.
It seems we need to figure out what we should do to address such issues
in the future. I think there are three options:
1. Stop providing these bundles altogether and just rely on the
official artifacts from the OSGi Alliance (I believe they are in a
maven repo somewhere).
2. Provide them with their full explicit dependencies (i.e., static
Import-Package declarations).
3. Divide them up into more reasonable chunks, since they lack
cohesion as bundles which makes managing their dependencies more
unreasonable (e.g., it sucks having to deploy a provider of
javax.microedition.io for org.osgi.service.io when you just want
to use logging).
At this point, I think the order of the options listed here is the order
of my preference.
I talked to Tom Watson about this and he agrees, saying he thinks their
bundles are a mistake and doesn't plan on updating them. His recommended
approach for the future is to bundle the API with the implementations.
Sounds good to me, since that's what we do too. What do you guys think?
-> richard
