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:
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.