dynamic plugins > deactivating plugins


Deactivating plugins is the act of moving an activated plugin to deactivated state. This does not remove it from the registry but runs the plugin's shutdown lifecycle and returns the plugin to the same state as it was before it was activated (i.e., when the platform started). All extensions and extension-points remain in place in the registry.

There are two reasons for deactivating a plugin:

  1. regain some space by removing any structures required by the plugin and recovering the space required for its classes.
  2. as a prelude to removing the plugin from the registry, also known as disablement (see glossary).

Note that deactivating a plugin A which is required by plugin B does not imply the B must be deactivated -- just as activating B does not imply that A is activated.

Deactivating a plugin does not itself require additional lifecycle events. However, in general, other plugins have references to newly deactivated classes/objects and the plugin being deactivated may not cleaned up after themselves. As a result, some notification will be required to tell plugins to clean up their structures.

A plugin that is being shutdown should clean up its internals to limit the number of external references it might have. However, it is often other plugins have references to instances of the deactivated plugin's classes (e.g., the resources plugin references supplied builder classes). This prevents those classes and thus the plugin's classloader from being garbage collected.

One simple approach that can be implemented in the Eclipse runtime infrastructure is to manage instances created via createExecutableExtension(). This is the method used to create instances of classes provided via extensions to extension-points. Since this code path goes through runtime code, the runtime could track instances created and at report on plugins which retain references after a plugin is deactivated. For more details, see managing classloaders and instances.

Another approach simply broadcasts the deactivation notice and plugins hosting extensions from the plugin being deactivated are responsible for the cleanup.

Pragmatically, both approaches should be supported.

Notification mechanism
The notification mechanism will only broadcast "Plugins events". As a reminder the events are "activated" and "deactivated".
The notified plugins will at least be:

The infrastructure for the following notification mechanism is: Is there a necessity to have a notification before and after the actual state change?
Is there a necessity of registring to those events through extension points?
What about letting the plugin decide wheter or not it wants to be deactivated on the deactivation of a prerequisite deactivation?

See also: