[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Plugin development


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