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
possible.
>>
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).
> Tom
Thanks for the info.
Rick Litton
