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
>> 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 :
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 :
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
Thanks again for your help, Alan.
Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> Sent by: equinox-dev-admin@xxxxxxxxxxx
Please respond to
Re: [equinox-dev] RCP, OSGi and all
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
> 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.
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.