[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Plugin development
- From: Peter Kriens <Peter.Kriens@xxxxxxxx>
- Date: Wed, 21 Apr 2004 16:05:50 +0200
- Delivered-to: email@example.com
- Organization: aQute
The autostart did the trick ... Should that not be the default
behavior? It does not feel good to load private classes from a bundle
and not start it before?
Still slightly confused with the multiple dependency files.
What is exactly the relation now between the MANIFEST.MF and the
plugin.xml? I understand they both have to be available (at least when you want to
use extension points)? If so, who defines the dependencies? They can be defined in the
manifest as well as in the plugin.xml.
JM> Great answers Martin. It is notonly OK but highly desired that others answer questions.
JM> By way of some more background...
JM> How you see the Eclipse runtime dependson where you are
JM> coming from. Martin has accurately described theEclipse
JM> perspective. Just write plugin.xml as normal and write aPlugin
JM> class that does not use the (soon to deprecated) methods on
JM> Plugin. List this guy as your plugin class and let the runtime
JM> take careof everything else.
JM> If you are coming at this from the OSGipoint of view, you can
JM> write a MANIFEST.MF and identify a bundle activator. In the
JM> traditional OSGi model you then have to arrange for someoneto
JM> "start" your bundle.
JM> The two models meet as follows. Pluginactually implements
JM> BundleActivator. When you list a Plugin class as theplugin class
JM> in your plugin.xml (and are not requiring compatibility),that
JM> Plugin class is actually used as the BundleActivator. As suchyou
JM> need to implement start() and stop(). Further, the
JM> transfromationfrom plugin.xml to MANIFEST.MF puts a special
JM> Eclipse-AutoStart: true headerin the manifest. This makes Eclipse
JM> automatically start the pluginwhen it loads a class for the first
JM> Martin Lippert <lippert@xxxxxxx>
JM> Sent by: equinox-dev-admin@xxxxxxxxxxxxx/21/2004 08:51 AM
JM> Please respond to
JM> Re: [equinox-dev] Plugindevelopment
JM> Hi Peter,
JM> hope it is okay if a non-runtime and non-committer guy try to answer
JM> 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
JM> From my understanding you should do something like this:
JM> 1. Create a new plugin and do *not* check the OSGi box in the new plugin
JM> wizard (this does not create a manifest file, which is only necessary
JM> for *very special* OSGi feature usage)
JM> 2. Replace the dependency to o.e.c.runtime.compatibility with o.e.c.runtime
JM> 3. Adapt your plugin class to the new plugin superclass from the general
JM> runtime plugin (replace the constructor with one without parameters)
JM> 4. Override start and stop methods in your plugin class (their you get
JM> 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.
JM> Your plugin should look pretty much like if you would have written it
JM> with Eclipse 2.1 (except from the default constructor and the new
JM> start/stop methods).
JM> The extensions.xml file was only a temporary idea during some older
JM> milestone builds of 3.0. (if I remember previous observations correct).
JM> 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?
JM> If you create your plugin the way I described above the runtime should
JM> take care of this.
JM> In your first try the wizard created a MANIFEST.MF file. In this case
JM> the runtime takes the dependency information of this file only (this
JM> caused the dependency confusion) and does not auto-activate the plugin
JM> (if you do not explicitly write it in the MANIFEST.MF)
JM> Hope this helps. And I hope I did not forget something.
JM> Best regards,
Peter Kriens Mob. +46705950899
34 Place René Nelli Tel. +33467871853
34670 Baillargues, France AOL: pkriens