The abstract superclass of all plug-in runtime class
implementations. A plug-in subclasses this class and overrides
the appropriate life cycle methods in order to react to the life cycle
requests automatically issued by the platform.
For compatibility reasons, the methods called for those life cycle events
vary, please see the "Constructors and life cycle methods" section below.
Conceptually, the plug-in runtime class represents the entire plug-in
rather than an implementation of any one particular extension the
plug-in declares. A plug-in is not required to explicitly
specify a plug-in runtime class; if none is specified, the plug-in
will be given a default plug-in runtime object that ignores all life
cycle requests (it still provides access to the corresponding
plug-in descriptor).
In the case of more complex plug-ins, it may be desirable
to define a concrete subclass of Plugin
.
However, just subclassing Plugin
is not
sufficient. The name of the class must be explicitly configured
in the plug-in's manifest (plugin.xml
) file
with the class attribute of the <plugin>
element markup.
Instances of plug-in runtime classes are automatically created
by the platform in the course of plug-in activation. For compatibility reasons,
the constructor used to create plug-in instances varies, please see the "Constructors
and life cycle methods" section below.
The concept of bundles underlies plug-ins. However it is safe to regard plug-ins
and bundles as synonyms.
Clients must never explicitly instantiate a plug-in runtime class.
A typical implementation pattern for plug-in runtime classes is to
provide a static convenience method to gain access to a plug-in's
runtime object. This way, code in other parts of the plug-in
implementation without direct access to the plug-in runtime object
can easily obtain a reference to it, and thence to any plug-in-wide
resources recorded on it. An example for Eclipse 3.0 follows:
package myplugin;
public class MyPluginClass extends Plugin {
private static MyPluginClass instance;
public static MyPluginClass getInstance() { return instance; }
public void MyPluginClass() {
super();
instance = this;
// ... other initialization
}
// ... other methods
}
In the above example, a call to
MyPluginClass.getInstance()
will always return an initialized instance of
MyPluginClass
.
Constructors and life cycle methods
If the plugin.xml of a plug-in indicates <?eclipse version="3.0"?> and its prerequisite
list includes org.eclipse.core.runtime
, the default constructor of the plug-in
class is used and
#start(BundleContext) and
#stop(BundleContext) are
called as life cycle methods.
The
#Plugin(IPluginDescriptor) constructor was called only for
plug-ins which explicitly require the org.eclipse.core.runtime.compatibility
plug-in. It is not called anymore as Eclipse 4.6 removed this plug-in.
If the plugin.xml of your plug-in does not indicate <?eclipse version="3.0"?> it is therefore
not a 3.0 plug-in. Consequently the
#Plugin(IPluginDescriptor) is used and
#startup() and
#shutdown() are called as life cycle methods.
Since Eclipse 3.0 APIs of the Plugin class can be called only when the Plugin is in an active state, i.e.,
after it was started up and before it is shutdown. In particular, it means that Plugin APIs should not
be called from overrides of
#Plugin().