[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Bundle Granularity?
- From: Toni Menzel <tonimenzel@xxxxxx>
- Date: Thu, 01 Feb 2007 21:53:06 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 126.96.36.199 (Macintosh/20061207)
About "We cannot treat these core classes as a real bundle":
Using an osgi framework to actually launch the one to be used at
application-level is a way i think.
Looks like a chicken-egg problem but nevertheless looks cool in my point
Thomas Watson schrieb:
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
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
> -> 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
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.
equinox-dev mailing list