equinox-dev-admin@xxxxxxxxxxx wrote on 11/08/2004
> >> plugin == bundle. The Eclipse runtime is 100% OSGi
> ultimately everything is a bundle to the runtime.
> >> The Eclipse Plugin class is simply a helper implementation
> BundleActivator. You can use it or not as you .. > >>
> But am I right in saying that bundle != plugin ?. What I mean is
> that if I wrote a bunlde in Oscar it would not be a plugin for
> Eclipse as is. Is it simply a case of creating a plugin.xml or is
> there more (or less) to it ?
This is a subtle but I believe a very important point.
I really (really) mean that plugin == bundle. Extensions and
extension points are a characteristic of the bundle called org.eclipse.core.runtime.
If that bundle is installed, it will read plugin.xml files (if any)
and do certain things with the information. This is no different
than, for example, bundles which supply web applications to a web container
mechanism installed as a bundle, or a bundle that requires some other service
supplied by other bundles.
That is, just because a bundle uses extensions/extension
points, or subclasses Plugin or... we do not stop calling it a "bundle"
and start calling it a "plugin". It is just a bundle that
> >> traditionally plugins have used plugin.xml
to describe their
> execution characteristics. This is still true in
> >> Eclipse today but under the covers, the Eclipse implementation
> generates manifest.mf files. Some plugins (e.g., >> SWT
> I believe) include manfiest.mf files out of the box. If you
> your plugin to run on any OSGi >> system you should craft/generate
> manifest.mf files.
> >> Like any system, if you require some function/code from some
> other component, that component must be installed
> >> for your code to work. So if you write a plugin that
> (for example) then you need SWT in your system. >> Similarly,
> you use the function supplied by the Runtime plugin (org.eclipse.
> core.runtime) then you need that >> plugin.
> I decided to test out running an Ecipse plugin in another OSGi
> implementation so I created a standard Hello World Plugin-in in
> eclipse and then packaged it as a jar file. I started it in
> Knopflerfish and got the following error :
> java.lang.NoClassDefFoundError: org/eclipse/ui/plugin/AbstractUIPlugin
> which I was expecting as the Hello World dependencies are org.
> eclipse.core.runtime and org.eclipse.ui.
Right. this is expected.
> Next I package the core.runtime as a jar and
started that in
> Knopflerfish and got the following error :
> java.lang.NoClassDefFoundError: org.eclipse.osgi.service.
> This I wasn't expecting.
The Eclipse runtime bundle requires the EnvironmentInfo
(and other) service. In the Eclipse OSGi this service is supplied
by the framework (i.e., it is always there). In other implementations,
someone else will need to implement/supply the service.
>This class is in the eclipseAdopter.jar file of
> org.eclipse.osgi plugin. So I went on to package this as a jar and
> again start it in Knopflerfish and got the following error :
> at org.eclipse.osgi.framework.internal.core.
> and then I was stumped. I was hoping it was going to be as easy as
> starting core.runtime and ui in Knopflerfish but unfortunately no.
Right. the org.eclipse.osgi "bundle" is
actually the OSGi framework implementation itself. It is the System
Bundle so you cannot take it and install it in another OSGi framework.
> Am I making a mistake somewhere ?
The root of the evil here is that the Eclipse OSGi
implementation supplies various services and the rest of the Eclipse bundles
make use of these. We have always been interested in running Eclipse
on other OSGi implementations but have never had the time to work it through.
While I'm sure there will be hiccups, I'm pretty sure it can be done
with relative ease. (Issues like the Eclipse auto-activation model
will be a problem)
The thing to keep in mind here is that OSGi leaves
alot of things undefined. They do not talk about how bundles are
laid out, how they get installed, how do they get started, ... Eclipse
has put in place structures for these things. Other OSGi implementations
may or may not have done so. If they have, the approaches are likely
> Also on a slightly different note we are currently
> running Java applications on a PDA (PocketPC to be specific). I have
> successfully used the IBM J9 VM to run a simple SWT example on it.
> I then read that the IBM SMF was an OSGi implementation that could
> run on a PDA and I started thinking of the possibilites of running
> an RCP on a PDA. Is this something that is possible/being considered
at all ?
Absolutely! I personally have done this and
it is one of the main focuses of the eRCP project. We are actively
pursuing a reduction in our class library requirements (i.e., requiring
only CDC Foundation) up the Eclipse bundle stack. Various people
in the community have been trying this and have been reporting bugs/patches
where they have found uses of non-Foundation code. Note that this
only applies to the RCP plugins. There is no push to move the higher-level
(e.g., IDE, JDT, ...) plugins onto Foundation.
I'm very happy to see you and others pushing on this.
It is definitely a direction of interest and in which we need your
help to ensure we meet the needs.