On 5/15/09 1:50 PM, Felix Meschberger wrote:
Hi,
Richard S. Hall schrieb:
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.
IIRC the official bundle jars als have DynamicImport-Package, but maybe
a bit more specific. I think we once had static imports which resulted
in the bundle jars being unusable due to required dependencies (see your
third point below).
I am not saying that the official bundles will solve the issue, but at
least we can wash our hands of it since they are not our artifacts.
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 would apply the same order, though I don't particularly like number 2
due to the "hard" dependencies, unless those are declared optional.
Optional dependencies are no better than dynamic ones in this case
because it will still allow the packages to be used without having their
_real_ dependencies resolved. The issue is that we are pretending the
dependencies are optional to avoid having to deal with resolving the
dependencies since it is a pain. A recipe for disaster.
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?
I am split on this. Consider a logging bundle which exports the OSGi Log
Service API. Almost all bundles will wire to that due to this. Then
updating the log bundle will cause massive rewiring....
I don't think, that this is really the intent. So while I agree, that
implementations should generally also export the respective official
OSGi API, we might still want to have a specific "OSGi API bundle".
Well, I think we already encourage people to do this and this was (is?)
recommended by the spec. You are correct, though, that it creates some
issues if you want to refresh.
However, if you fix an impl detail in the impl bundle, then it is not
necessary to refresh the framework, since the older bundle revision will
still be exporting its API packages and the new revision can just wire
to those packages. The impl just needs to remember to export/import the
API packages. Then refreshing can happen at your leisure.
-> richard
