RE: [equinox-dev] Bundle Granularity?

[Thomas Watson <tjwatson@xxxxxxxxxx>]

equinox-dev-bounces@xxxxxxxxxxx wrote on 02/01/2007
01:22:27 PM:

> Hi Tom,
>  
> Please refer to my responses below.
>  
> Rick Litton

> There are a few reasons we package the core org.osgi classes in the
> framework implementation (org.eclipse.osgi) 
> 
> 1) Packaging convenience.  Having all the org.osgi.* classes
> packaged directly in the framework implementation reduces the amount
> jars you need to find and place on the classpath of the framework.
> -> I was assuming that the osgi bundles will be auto-started and
> that the required packages are exported which can then be imported
> by org.eclipse.osgi.  I haven’t actually done this but I think
it should work.

The OSGi framework is not loaded with an OSGi classloader.
 It has no 
ability to reach out into a bundle to load classes
via Import-Package.  
Especially core classes in the org.osgi.framework
package that are needed 
to implement the Framework itself.

> 2) Technically we need to modify some of the classes provided by the
> OSGi Alliance to hook into our implementation.  For example,
> FrameworkUtil, AdminPermission and BundleSignerCondition. 
> -> Can we get away with just extending the
osgi interfaces?  I guess
> I find changing someone else’s framework classes/interfaces unappealing.

The OSGi specification states that implementations
are free to modify 
the OSGi classes to hook in to their implementation.
 We cannot 
simply extend classes like FrameworkUtil because that
is the class 
that other bundles will reference, not our extending
class.  That 
would create a containerism.

Felix project is also packing the org.osgi packages
in the felix
framework for the same reason.

> 
> 3) Working on future reference implementations for the OSGi 
> Alliance.  We need the ability to modify the API with enhancements
> that will become available in future public OSGi specifications.  
> For example, we are currently working on the Reference 
> Implementation for OSGi R4.1 which introduces a small number new methods.
> -> Personally, I think that this is even an
important consideration.
> Switching OSGi R4 bundles with OSGi R4.1 ones will be a “snap” 
> (hopefully) when they become available.  Like everyone else,
I 
> suppose OSGi will also provide maintenance or versioned releases to
> fix defects, etc.  It would be expedient to simply switch to
those 
> versioned ones without having to release an Equinox distro in 
> response.  In this sense, tight coupling has its disadvantages
in my view. 
> 

We cannot treat these core classes as a real bundle,
I can see some value 
in having the jar separate from the org.eclipse.osgi
jar but it adds 
complication when launching the framework because
you need to find an 
osgi.jar that is compatible with the framework implementation.

Tom