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.
Peter Kriens <Peter.Kriens@xxxxxxxx> Sent by: equinox-dev-admin@xxxxxxxxxxx
04/21/2004 10:05 AM
Please respond to
Re: [equinox-dev] Plugin
The autostart did the trick ... Should that not be
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
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
>> a hell of a time ... maybe someone can help.
>> My plugin needs the bundle context so I need a bundle activator.
>> seems however that this never gets called, not even the constructor.I
>> created a new plugin project, checked the OSGi box and looked
>> 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
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
JM> runtime plugin (replace the constructor with one without parameters)
JM> 4. Override start and stop methods in your plugin class (their you
JM> the BundleContext as parameter)
>> Originally I had an extensions XML file instead of a plugin.xml
>> (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
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
JM> take care of this.
JM> In your first try the wizard created a MANIFEST.MF file. In this
JM> the runtime takes the dependency information of this file only (this
JM> caused the dependency confusion) and does not auto-activate the
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,
34 Place René Nelli
34670 Baillargues, France
equinox-dev mailing list