Skip to main content

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



Alan,

Correct, a bundle is not necessarily an eclipse plugin.

To make it an eclipse plugin, all you need is to give it a plugin.xml and
prefereably make it part of an eclipse feature.  Inclusion in a feature is
necessary for deployment via the update manager and to track in the
configuration maintained by the org.eclipse.update.configurator.   Using
features is not 100% mandatory, but I recommend it.

With a 'modern' (eclipse 3.0) plugin, the main use of the plugin.xml is for
the registration of extension-points and extensions into the eclipse
extension registry, which is the primary aspect of eclipse that is distinct
from the osgi runtime.   You can continue to use a manifest for the
definition of the classloader namespace (exports /imports, etc.).

As to running eclipse plugins in a different osgi.  Keep in mind that when
eclipse loads an eclipse plugin, if it doesn't have a conformant
manifest.mf, eclipse will generate one based on the dependancy information
expressed in the plugin.xml (if found there).  The result is an osgi
manifest.mf that is used to actually load the plugin as a bundle into the
runtime.   By 'conformant' I mean that they need to use the headers defined
by the OSGi 4 rfcs such as 'Bundle-SymbolicName', etc.   You can find the
generated manifests in the configuration directory in the org.eclipse.osgi
directory.

When you jarred up your plugins and deployed them into KnopplerFish (I'm
not familiar with that), did you use the appropriate generated manifests
(if necessary)?

Also, for this scenario to work, knopplerfish would need to be happy or at
least tolerant of the extended header definitions from the osgi 4 rfcs that
eclipse 3 uses.

You CAN make an eclipse plugin that has no dependencies on org.eclipse.*
plugins, btw.    That would be easier to move to a different runtime.

-mel

A.Morgan@xxxxxxx wrote on 11/08/2004 12:00:04 PM:

>
> Hey Jeff,
>
> Thanks for the explanation...it has cleared up some of the confusing
> issues I was wondering about in relation to Eclipse and OSGi.
> A couple of more observations/questions  :
>
>
>
> >> 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 ?
>
> >> 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 and Runtime I
> believe) include manfiest.mf files out of the box.  If you want 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 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.
> 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. 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(SystemBundleActivator.java:38)
>
> 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. Am I
> making a mistake somewhere ?
>
>
>
> 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 ?
>
>
> Thanks again for your help,
> Alan.
>
>



Back to the top