Re: [equinox-dev] Bundle Granularity?

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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.

Tom.

> 
> kind regards,
> Toni
> 
>