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


From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Watson
Sent: Thursday, February 01, 2007 12:36 PM
To: Equinox development mailing list
Subject: RE: [equinox-dev] Bundle Granularity?


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.


Which is true.  It’s the chicken and egg scenario and causes problems with a mixed framework

(e.g. mixing Equinox and Felix) scenario.  I was actually looking for a mix and match solution if it was all


>> 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.

It’s actually the focus of another project I’m currently working on (outside of work).  Creating a container

that allows for a “shell-like” environment that encapsulates components from different

frameworks seems to be a possible solution.

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

Yes, again this is true.  Classloading is a major problem with OSGi framework

Implementations and I wonder if what you mentioned as an “OSGi classloader”

is a feasible approach.  Has anyone ventured into this?

>> 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.

This certainly is a problem especially since OSGi allows for modifying core classes.  But

we are putting our thinking hats on to possibly get around this (we hope).    



Thanks for the info.


Rick Litton