This RFC highlights the need for bundles to express their dynamic capabilities and proposes a solution based on the introduction of a new header in the manifest.mf.
Last modified: Decemver 1, 2004 - revision 2, previous revision
In 3.0 the concept of a dynamic plugin has been introduced. Even though some infrastructure has been added, plugins did not become automatically / magically dynamic. Some work was expected by the plugin writers. This resulted in the eclipse 3.0 SDK being only partially dynamic possibly leading to strange behavior. Indeed, because the runtime and some other plugins are dynamic, it is possible to install and uninstall plug-ins and be under the impression that everything worked fine. For example if a new builder is being added, it will not be picked up because org.eclipse.core.resources is not dynamic aware.
Being able to detect such things is important for the user, since they can lead to incorrect behavior of the system.
Plugins must be able to express their dynamic capabilities in order to enable runtime and development time checks. This markup is purely descriptive and will not interfere with the behavior of plugins. There is several levels of dynamic capabilities:
Because being dynamic is not a property reserved for bundles declaring extensions, this characteristic is being captured in the bundle manifest by the following header: Eclipse-Dynamic: whose values are either enabled, addition-aware, removal-aware or unspecified and are separated by semi colons. It is important to note that there is no relation among the values. For example being addition-aware does not include enabled.
Eclipse-Dynamic: enabled; addition-aware; removal-aware
Eclipse-Dynamicis absent from the manifest.mf, or that are generated from plugin.xml.
for all P's prerequisite (transitively) if prereq is addition-aware OK else if prereq is not active OK else return Need to reboot end if end if end for return OK;
When a plugin P is being removed from a running instance of eclipse
for all P's prerequisite (transitively) if prereq is removal-aware OK else if prereq is not active OK else return Need to reboot end if end if end for for all plugins requiring P if requiringPlugin is not enabled && requiringPlugin is active return Need to reboot end if end for return OK;
Given that the format of a manifest.mf is open ended, the addition of this new header can be done immediatly.
The first change to do is to update the PluginManifest converter to generate default values.
PDE and other configurators can be updated at their own schedule.
1 - Runtime defines an extension point and every plugin declares by an extension it dynamic capability. This has the drawback of forcing the addition of a plugin.xml in all pure bundle (like junit, tomcat, swt).
A varient on that was to provide a generic extension point for people to declare other capabilities such as "running without instance location" , "running without configuration location".
Given that the manifest is open ended, those capabilities can be expressed in the manifest if needed.
2 - Special markup in the plugin.xml. Drawbacks are the same than in the previous solution and more over it was requiring PDE and runtime to change their plugin parsers.