[news.eclipse.technology.equinox] Re: Eclipse - OSGi Comparison

["ted stockwell" <ted.stockwell@xxxxxxxxxx>]

"Olivier Gruber" <ogruber@xxxxxxxxxx> wrote in message
news:b3e9b2$frb$1@xxxxxxxxxxxxxxxx
>
> One of the first advantages is to leverage an existing open standard
rather
> than reinventing the wheel. When Eclipse started, OSGi was also in its
> infancy and therefore an unlikely choice. Since then, Eclipse and OSGi
have
> both evolved toward a surprising similarity, as we will discuss in the
> following paragraphs. We therefore feel that Equinox above an OSGi
platform
> would create a much-needed synergy in the Java community.
>
Ditto this.
As you have pointed out in your other posts, there are differences between
how Eclipse and OSGi export/import packages, how they load plugins/bundles,
etc.  Do you have a feel for how significant these differences really are?
I suspect that most plugins could easily be ported to bundles and the
differences in platform semantics would be easily resolved.  Also, the
plugin container that you envision could probably hide most of the
differences from plugins.
I think that supporting OSGi would buy Equinox an instant community of
supporters.

>
> Another advantage would be the separation of concerns between Java
> components and plug-in specifics. If Equinox would be a plug-in container
> above an OSGi foundation, an Equinox plug-in would be an OSGi bundle that
> defines extensions or extension points. The Java imports and exports are
> expressed within the bundle manifest. The extensions and the extension
> points are expressed in the plugin.xml, as an extra manifest without the
> "require" and the "runtime" tags.
>

I have read your other posts.  I think the idea of an OSGi-based  'Java
layer' that can install/update bundles is very well reasoned and right on
target.  OSGi definitely needs the update facility that Eclipse can provide
and OSGi would improve the 'self hosting' story in Eclipse.

I think the idea of a plugin container bundle is another good idea.
How about workspaces?  I see the Eclipse workspace API as belonging to the
plugin container.  The workspace API may be implementable on top of the OSGi
Persistent Storage Facility.

>
> It is interesting to point out that OSGi and Eclipse have taken two
> different routes to control exports. An OSGi bundle specifies its exports
as
> a list of Java packages, all other packages are private. Eclipse by
default
> exports all Java packages from a plug-in but allows for a filter. I am not
> sure one mechanism is essentially better technically. However, I always
felt
> that a full encapsulation as a default policy is better, forcing explicit
> exports when needed.
>

Another difference between OSGi and Eclipse is that OSGi bundles can export
packages to other bundles and those packages will be available to other
bundles even if the other bundles do not explicitly import the packages.  I
have found that low level plugins absolutely need this capability (like
plugins that are responsible for deserializing objects coming in on the
wire, those plugins will need to basically import almost every other plugin,
it's nasty).


ted stockwell