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.

• all the plugins in the transitive closure of the deactivated plugin
• plugins depeding on the deactivated plugin
• plugins providing extensions to the deactivated plugin
• plugins to which the deactivated plugin provide extensions

- a PluginEvent class flagged with "actived" or "deactivated" as well as a collection of plugins;
- a registration mechanism;
- addition of a method in the Plugin class to receive the notification (the method will come from an interface);

See also:

• usecases