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


Peter, this is the OSGi way!  OSGi expects that there is a magic agent doing the start() and stop() of bundles.  In Eclipse scenarios we dont' have such an agent so the system acts as one.  People coming from the OSGi mindset do not expect their start() to be called automatically so have no expectiation of bundle state when their code is executing.  As such, the default when you write your own MANIFEST.MF is to NOT autoactivate.  If you write a plugin.xml and do nt have a MANIFEST.MF then you are signalling that you are an Eclipse person and expect autoactivation.

Dependency files:  Martin got it right.  MANIFEST.MF is it.  As a convenience to old Eclipse folks we will transparently create a MANIFEST.MF if one is not found.  The creation uses the plugin.xml and associated code jars as input.  If you have both an plugin.xml and a MANIFEST.MF then any dependency annotations in the plugin.xml are completely ignored.

Going forward the plugin.xml should contain only the Eclipse layer stuff (e.g., extensions, extension points).  Dependencies etc will be spec'd in the MANIFEST.MF.  We need to have a good editor story for that first.

Jeff




Peter Kriens <Peter.Kriens@xxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

04/21/2004 10:05 AM

Please respond to
equinox-dev

To
Jeff McAffer/Ottawa/IBM@IBMCA
cc
equinox-dev@xxxxxxxxxxx
Subject
Re[2]: [equinox-dev] Plugin development





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.

Kind regards,

    Peter Kriens


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> time.

JM> Jeff



JM> Martin Lippert <lippert@xxxxxxx>
JM> Sent by: equinox-dev-admin@xxxxxxxxxxxxx/21/2004 08:51 AM

JM> Please respond to
JM> equinox-dev


JM> To

JM> equinox-dev@xxxxxxxxxxxxx

JM> Subject

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
>> file.

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,
JM> -Martin





--
Peter Kriens                              Mob. +46705950899
34 Place René Nelli                       Tel. +33467871853
34670 Baillargues, France                 AOL: pkriens

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/equinox-dev