[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/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