Markup to express bundle dynamic capabilities.

Summary
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

Background

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.

Proposed solution

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:

• A bundle / plugin can be dynamic enabled."Most importantly, to be dynamic enabled, your plug-in has to properly clean up after itself in the Plugin shutdown method." ( FAQ 117). This is the behavior that has been recommanded since eclipse 1.0.
• A bundle / plugin can be addition aware. It will take into account new bundles being added to the system. For example this means tracking extension / extension poins and/or new bundles being installed, started.
• A bundle / plugin can be removal aware. It will take into account bundles being removed from the system. For example this means tracking extension / extension poins and releasing the objects from the bundles being uninstalled.
• A bundle / plugin can be not dynamic at all.

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

Default values

Usage

Tools

• PDE which given a target platform could check if all plugins are dynamic enabled, support removal, etc.
• Configurators and installers could check on addition or removal if the system needs to be restarted.

Recommanded usage behavior

	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;

Changes required

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.

Other solutions considered

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.