Re: [equinox-dev] Plugin development

[Martin Lippert <lippert@xxxxxxx>]

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature