[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Bundle Granularity?

equinox-dev-bounces@xxxxxxxxxxx wrote on 02/01/2007 01:56:15 PM:

> i think the current packaging granularity has much to do with the mantra
> 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. and
> 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 java
> 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 say, too)
> 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 to
> the community. this implementation should be exchangable to save the
> open source mantra i think. If I understand Tom's "hook into it" this
> isn't possible currently, is it?
> Here we have a good example for the anti-forces "tight coupling" or
> "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 implementations.


> kind regards,
> Toni