Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] RCP, OSGi and all that

equinox-dev-admin@xxxxxxxxxxx wrote on 11/08/2004 06:14:51 AM:

> >> plugin == bundle.  The Eclipse runtime is 100% OSGi based so
> ultimately everything is a bundle to the runtime.
> >> The Eclipse Plugin class is simply a helper implementation of
> BundleActivator.  You can use it or not as you .. > >> choose.
> 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 files.  Some plugins (e.g., >> SWT and Runtime
> I believe) include files out of the box.  If you want
> your plugin to run on any OSGi >> system you should craft/generate
> 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 uses SWT
> (for example) then you need SWT in your system.  >> Similarly, if
> 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.
> environment.EnvironmentInfo
> 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 the
> 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 :
> java.lang.ClassCastException
>         at org.eclipse.osgi.framework.internal.core.
> SystemBundleActivator.start(
> 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 different.

> Also on a slightly different note we are currently looking at
> 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.


Back to the top