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


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.





Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

05/11/2004 14:11

Please respond to
equinox-dev@xxxxxxxxxxx

To
equinox-dev@xxxxxxxxxxx
cc
Subject
Re: [equinox-dev] RCP, OSGi and all that






equinox-dev-admin@xxxxxxxxxxx wrote on 11/05/2004 04:59:33 AM:

> Hey Jeff,
>
> I read your reply to Armand below with interest. I was looking into
> the whole area of the RCP and OSGi etc and I have a few questions
> which you may be able to clear up for me if you had a few minutes.
>
> 1. I understood that as from Eclipse 3.0 new versions of plugins
> that were installed would be picked up by the OSGi framework
> underlying Eclipse and so a restart was not required. However I have
> not been able to do this and have had to restart to pick up the new plugin.
> Am I missing something ?


This really depends on how you install them. If you use update manager for example, yes, they are picked up.  If you just drop them in the plugins dir, no they are not immediately noticed.  


> 2. I was playing around with two OSGi 3.0 implementations (Oscar and
> Knopflerfish) and was able to write bundles on each and run it on
> the other as you would expect. However my question regarding Eclipse
> is  whether a plugin to Eclipse can be run as a bundle on another
> OSGi implementation. I was thinking that this wasn't possible as a
> plugin subclasses an Eclipse class which then implements BundleActivator.
> So I guess my question is whether you can take an Eclipse plugin and
> run it in another OSGi implementation ?


Great question. Several points to observe here

- plugin == bundle.  The Eclipse runtime is 100% OSGi based so ultimately everything is a bundle to the runtime.


- 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.


- The Eclipse Plugin class is simply a helper implementation of BundleActivator.  You can use it or not as you choose.


- The Eclipse OSGi framework implementation is R3.0 compliant.  So if you use R3.0 function and have all the prerequisites, your plugin/bundle should run on other OSGi implementations (and vice versa)


- The Eclipse OSGi framework implementation includes various additional function/capabilities.  These changes have been proposed to the OSGi community for inclusion in the R4 spec and those discussions are progressing.  If you use these additional capabilities in your bundle, it is unlikely to run on another framework implementation.


So the summary here is that yes, they are compatible but Eclipse has a large amount of additional capabilities.  To write bundles that will run anywhere you have to be sure to use the common subset.  We are very keen on aligning all these points but it will take some time.  For example, as we go forward and the OSGi R4 spec is finalized and is implemented by others, the ability to move plugins/bundles around will increase.  


Jeff


This email is intended solely for the use of the named addressee(s). Any unauthorised disclosure, copying or distribution of the confidential information contained therein, or the taking of any action based on it, is prohibited. The sender disclaims any liability for the integrity of this email. Legally binding declarations must be in written form.