Re: [equinox-dev] Plugin development

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Great answers Martin.  It is not
only OK but highly desired that others answer questions.

By way of some more background...

How you see the Eclipse runtime depends
on where you are coming from.  Martin has accurately described the
Eclipse perspective.  Just write plugin.xml as normal and write a
Plugin class that does not use the (soon to deprecated) methods on Plugin.
 List this guy as your plugin class and let the runtime take care
of everything else.

If you are coming at this from the OSGi
point of view, you can write a MANIFEST.MF and identify a bundle activator.
 In the traditional OSGi model you then have to arrange for someone
to "start" your bundle.

The two models meet as follows.  Plugin
actually implements BundleActivator. When you list a Plugin class as the
plugin class in your plugin.xml (and are not requiring compatibility),
that Plugin class is actually used as the BundleActivator.  As such
you need to implement start() and stop().  Further, the transfromation
from plugin.xml to MANIFEST.MF puts a special Eclipse-AutoStart: true header
in the manifest.  This makes Eclipse automatically start the plugin
when it loads a class for the first time.

Jeff

Martin Lippert <lippert@xxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

04/21/2004 08:51 AM

Please respond to
equinox-dev

To	equinox-dev@xxxxxxxxxxx
cc
Subject	Re: [equinox-dev] Plugin development

Hi Peter,

hope it is okay if a non-runtime and non-committer guy try to answer 
this question...

> I am trying to get my plugin to work (again) under M8 and I am having
> a hell of a time ... maybe someone can help.
> 
> My plugin needs the bundle context so I need a bundle activator. It
> seems however that this never gets called, not even the constructor.
I
> created a new plugin project, checked the OSGi box and looked at it.
> But as far as I can see, it never calls the activator automatically
> either if a view is created. This standard plugin creates a plugin.xml
> file.

 From my understanding you should do something like this:

1. Create a new plugin and do *not* check the OSGi box in the new plugin
wizard (this does not create a manifest file, which is only necessary 
for *very special* OSGi feature usage)
2. Replace the dependency to o.e.c.runtime.compatibility with o.e.c.runtime
3. Adapt your plugin class to the new plugin superclass from the general
runtime plugin (replace the constructor with one without parameters)
4. Override start and stop methods in your plugin class (their you get
the BundleContext as parameter)

> Originally I had an extensions XML file instead of a plugin.xml file
> (and a manifest of course). However, Eclipse seems to get totally
> confused about the dependencies when there is no plugin.xml.

Your plugin should look pretty much like if you would have written it 
with Eclipse 2.1 (except from the default constructor and the new 
start/stop methods).

The extensions.xml file was only a temporary idea during some older 
milestone builds of 3.0. (if I remember previous observations correct).
In M8 you should put the extensions in the normal plugin.xml file.

> So can someone tell me how I should setup a plugin where the bundle
> activator is called before an extension is created?

If you create your plugin the way I described above the runtime should
take care of this.

In your first try the wizard created a MANIFEST.MF file. In this case 
the runtime takes the dependency information of this file only (this 
caused the dependency confusion) and does not auto-activate the plugin
(if you do not explicitly write it in the MANIFEST.MF)

Hope this helps. And I hope I did not forget something.

Best regards,
-Martin