equinox |
This approach to a dynamic registry clearly separates between the roles of the update manager, the platform, and the plugin registry. In this approach, we extend the life cycle of plugin through extending the Plugin class. The Plugin class already had the start and shutdown method, key to the programming model of plugins. This approach feels that dynamic events around extensions and extension points are as central to the programming model. Having them as part of the Plugin class stresses the importance of handling those events, as it is the case for start/shutdown. We envision three levels of dynamicity.
Loading and unloading is the first life cycle for a plugin. For a plugin to be loaded, it has to be known to the Eclipse platform. The most common way is through installing a feature through the update manager. When installing a feature, the update manager downloads its plugins and declares them to the Eclipse platform.
Once a plugin is know to the platform, it can be loaded—where it becomes know to the plugin registry. A plugin is first loaded in the disabled state. A disabled plugin may be unloaded, in which case the plugin registry forgets all about it. Of course, the platform remembers about all installed plugins, allowing to reload it later on if necessary.
Once loaded, a disabled plugin may be enabled. Enabling a plugin attempts to resolve all the plugin prerequisites. The prerequisites are first in terms of required plugins. Once all required plugins are found, the plugin is said to be resolved, in the traditional Java sense of a class being resolved. A class is resolved when all its imports are available. The same applies to plugin.
If the registry fails to find approriate versions of the required plugins, the enabling of the plugin fails. However, contrary to what happens today, the plugin is kept in the registry as loaded and disabled.
If the plugin is resolved, it is basically enabled. This is all there is to it for library plugins—plugins without extensions or extension points. However, for non-library plugins, the enabling process does not stop there. Enabling a plugin also attempts to match the plugin extensions with the corresponding extension points. The provider of these extension points will be notified of the newly available extensions.
The last state of enabling a plugin is actually adding the plugin very own extension points. Indeed, a plugin may define extension points of its own. They are added to the registry and providers of extensions for those newly added extension points will also be notified.
Once a plugin is enabled, it may be activated if needed. Activated or not, an enabled plugin may later be disabled. If the plugin is activated, it will be deactivated first, see deactivation. Once disabled, it can be further unloaded, which completes the registry life cycle. For the update manager, life cycle goes one step further, allowing the plugin to be uninstalled. Once uninstalled, there is no longer any trace of the plugin locally.