equinox-dev-bounces@xxxxxxxxxxx wrote on 02/01/2007
> i think the current packaging granularity has much to do with the
> in eclipse "one bundle per project" or "one project
per bundle" which
> forces larger bundles in a subtle way. (it's just a naming thing.
> project is an old term with much impact baked into it from a semantic
> point of view)
Not really, we could put the osgi classes in a separate
bundle, but the classes we need to modify would still need to
be contained in the org.eclipse.osgi project so they could have access
to the internals of our impl. This would create a dreaded "split"
package. Also, some of the classes in the standard osgi bundle would
need to reference the classes included in the framework, making for
a rather tricky circularity issue. Felix has the same problem
and also packages the osgi classes with their implementation. The
Eclipse "one bundle per project" or "one project
per bundle" stance certainly is not why they did this because they do
not use PDE to develop bundles.
> some more notes on
> 1. this convinience issue is mostly driven by the fact that usual
> packaging (jars) isn't really made to match with more advanced packaging
> methodologies (as osgi is).
> It's by the way a reason why handling osgi bundles with a static and
> jar-driven maven is still pretty brittle (as peter kriens likes to
> 2+3: it's a difficult thing for equinox building/enforcing the next
> specification on one hand and give a top-class osgi R4 implementation
> the community. this implementation should be exchangable to save the
> open source mantra i think. If I understand Tom's "hook into
> isn't possible currently, is it?
> Here we have a good example for the anti-forces "tight coupling"
> "redundancy" ..
The Framework is always going to be tightly coupled
to the version of the OSGi specification that it is implementing. This
goes back to an earlier discussion we've had on whether service interfaces
should be packages with the impl bundles or not. The framework
includes the osgi classes and exports them. It does not import
the packages because it is not possible for the framework's classloader
to be wired to osgi bundles before the framework is created.
It is unclear to me what you are actually trying to
do with the implementation. If you are trying to use the
framework jar as an actual bundle installed on another framework then
I can understand the dilemma. The org.eclipse.osgi jar was never
designed to be used this way. Instead we have an org.eclipse.equinox.supplement
bundle that contains the necessary equinox packages needed
to run the other "normal" equinox bundles (org.eclipse.equinox.registry,
org.eclipse.equinox.common etc) on other framework