equinox
dynamic plugins > deactivating plugins > usecases
|
|
Usecase: The Resources Plugin |
The resources plugin is central to Eclipse as a tooling platform and is very
likely to be referenced (classes or instances) from many plugins. Moreover the
resources plugins is offering several important extension-points (markers, builders,
natures). We will use it as the canonical case for plugin deactivation. That
is, we will study the plugin mechanism through two points of view: "deactivation
of a plugin based on the resources plugin" and "deactivation of the resource
plugin itself".
Deactivation of a plugin based on the Resources plugin:
Convention: PA always named the plugin being deactivated.
- Markers:
Could we be more precise here, in regards of type versus
object references between the resource plugin (extension-point provider) and
other plugins? Also clearly separating cross-plugin references from side effects
in the abscence of cross-plugin references.
a plugin can define its own marker type and instantiate any marker type (without
necessary referencing the plugin defining the marker). Markers can be persistent
or not. The case of persistent markers does not cause problems because they
are always stored. The case of non-persistent markers is more problematic.
- a plugin PA created non-persistent markers that it defines, PA is deactivated.
Shall the markers be cleaned-up, if yes should it be the responsibility
of the resources plugin or of PA?
- plugins P1 and P2 created non-persistent markers that are defined by
PA, PA is deactivated. Shall the markers be cleaned-up, by who? JohnA:
I think when a plugin is deactivated, you should never get rid of markers
that are of types defined by that plugin. So if PA defines a marker type,
and P1 and P2 use markers of that type, then deactivation of PA should
not affect those markers. This is symetrical with the fact that defining
a marker of a type defined by plugin 'P' does not require activation of
plugin 'P'. I think markers should only be removed when the plugin that
added the markers is deactivated.
*** Questions:
- Does a plugin being deactivated imply that its markers should be removed?
Relate this to the possibility that the plugin was never activated. It's
markers could still be shown since other plugins can create them.
- What is the semantics of persistent/transient
markers?
Persistent markers are saved by the platform when
it is shutdown, whereas transient ones are dropped.
- Session properties: Session properties are key/value pairs that are
associated with resources. By convention the key is qualified by the plugin
id. The value can be any Object. Because session properties may hold on to
any Object, it is important that they be removed thus enabling the plugin
defining the value class to be collected. Because there is no way for the
resource plugin to know who created a given property, the clean-up must be
done by the plugin that created it.
It may also be possible to have a brute force mechanism which simply removes
any session properties whose value is an instance of a class from a particular
classloader (i.e., plugin). This would ensure the references are removed but
may damage some assumptions made by the declaring plugin. See the question
about when applying such a mechanism
- Persistent properties: nothing special.
- Builders: builders are contributed through extension-points and are
instantiated by the resource plugin (using createExecutableExtension). Builders
instances are always kept by the resources plugin.
- plugin PA contributes a builder, PA is deactivated.
The resources plugin gets notified and can destroy the builder. PA has
the opportunity to register as an ISaveParticipant and so can ensure that
the builder's state is saved before being destroyed. Note that it is the
workspace's responsibility to trigger the save.
I don't get that?
- Natures: natures are contributed through extension-points and are
instantiated by the resource plugin. Natures instances are always kept by
the resources plugin.
- plugin PA contributes a nature, PA is deactivated. The resources plugin
gets notified and frees the instance of the PA's natures.
- Listeners: the resources plugin offers a listener mechanism that
allow plugins to get notification about modifications that occur in the workspace.
Because there is no way for the resources plugin to know which plugin has
created which listener, there is currently no way for the resources plugin
do the clean-up itself. The removal of listeners is the resposibility of the
plugin that added them.
- Move/delete/validate hooks: (org.eclipse.core.resources.fileModificationValidator,
org.eclipse.core.resources.moveDeleteHook, org.eclipse.core.resources.teamHook)
These extension-points are specials in that they can only have one extension.
The instance of the extensions are handled by the resources plugin and will
be collected by it.
Deactivating the resource plugin itself
One important point to remember in the deactivation process, is that to instantiate
classes from P1, P2 must requires P1. The consequence is that when P1 will be
deactivated P2 will also be deactivated, and before P1 (see : deactivating
plugins).
More importantly, it means that we cannot deactivate
P2 if P1 is not ok to be deactivated...