Eclipse is designed as a modular platform, with the ability to install and use plug-ins to extend the core functionality. To achieve this, Eclipse is built upon OSGi, a open modular system for Java with six years of commercial use behind it. Although this is a necessary part of Eclipse's modularity, it's enhanced through the use of the extension registry and extensions/extension points.

In the previous episode , we looked at how to create a plug-in to place a button on the toolbar, such that when we clicked it it displayed a message “Hello, Eclipse World”. But how did that button get on the toolbar? The answer lies in Eclipse's extensions.

You can think of Eclipse as being something like a USB hub. There's a standard plug-in specification (OSGi/USB) which defines how the hub operates, and you can plug any device that you want into the hub. Some of these will be standard types – mice, keyboards and so on – and will work in the same way, regardless of what and how they actually operate. In our case, our toolbar buttton is like these USB devices; plug it in, and Eclipse instantly knows that the button is there, and so displays it on the toolbar. Unplug the device (or stop the plug-in) and Eclipse will remove the button. (You can even get more complex devices, such as a USB-to-FireWire converter that allows other devices to be plugged into it; we'll cover providing your own extension points in a future episode.) And, like USB, the whole process is dynamic, meaning that we can extend the capabilities of an Eclipse system at run-time.

Getting back to the toolbar buttton; how does Eclipse know whether we've plugged in a toolbar button, a menu, or an editor? The answer lies in another piece of meta-data that's provided in an Eclipse plug-in – the plugin.xml file. This contains a list of extension points provided or used by this plug-in; when the plug-in is installed, the extensions are registered with the IExtensionRegistry and events are sent to those interested that a new extension has been installed. (A similar event occurs when an extension is uninstalled.)

The Eclipse toolbar listens out for such extension installation, and when a new button is installed, displays the icon on the taskbar. When the icon is clicked on, the action class associated with the button is loaded and invoked. If the plug-in has not been started, then it's brought into life at this point, as long as it specifies the manifest header Eclipse-AutoStart: true (3.1+), Eclipse-LazyStart: true (3.2+) or Bundle-ActivationPolicy: lazy (3.3+).

The format of the plugin.xml file is a series of <extension> (or <extensionPoint> ) elements. Each extension/extension point used has an associated id , which is normally a fully qualified name similar to that of a Java package; in the case of our toolbar button, org.eclipse.ui.actionSets . So, the overall structure looks like:


<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.2"?>
<plugin>
<extension point="org.eclipse.ui.actionSets">
...
</extension>
</plugin>


All extensions are defined in the same way; in effect, the IExtensionRegistry acts like a giant hashtable-of-lists where org.eclipse.ui.actionSets is the key, and there are zero-or-more entries in the list. Installing and uninstalling a plug-in has the side effect of adding/removing the entry from that list, with the associated events generated for dynamic code to listen to.

The children of the <extension> can be any (well-formed) content; it's up to the consumer of the extension point (e.g. the toolbar) to understand what is supplied. In the case of the actionSets extension, it looks like this:


<actionSet label="Sample Action Set" visible="true" id="helloworld.actionSet">
<action icon="icons/sample.gif" class="helloworld.actions.SampleAction"
label="&amp;Sample Action" tooltip="Hello, Eclipse world"
menubarPath="sampleMenu/sampleGroup" toolbarPath="sampleGroup"
id="helloworld.actions.SampleAction"/>
<menu label="Sample &amp;Menu" id="sampleMenu">
<separator name="sampleGroup"/>
</menu>
</actionSet>


The toolbar reads the action sets available, and displays icons in the toolbar (from the /actionSet/action@icon attribute). A proxy class is used to trigger the loading of the helloworld.actions.SampleAction , which implements IWorkbenchWindowActionDelegate , and control is passed via the run(IAction) method.

If you're interested, you can even see the list of actions that are installed in an Eclipse workbench using the following code, which you can paste into the code for the SampleAction 's run(IAction) method:

StringBuffer buffer = new StringBuffer();
IExtensionRegistry reg = Platform.getExtensionRegistry();
IConfigurationElement[] extensions = reg.getConfigurationElementsFor("org.eclipse.ui.actionSets");
for(int i=0;i<extensions.length;i++) {
  IConfigurationElement element = extensions[i];
  IConfigurationElement[] children = element.getChildren("action");
  for(int j=0;j<children.length;j++) {
    buffer.append(children[j].getAttribute("label"));
    buffer.append('\n');
  }
}
MessageDialog.openInformation(
  window.getShell(),
  "Installed plugins",
  buffer.toString());

We've covered the purpose of extensions and extension points in this episode; over the next few episodes, we'll be looking at some of the standard extension points that you can contribute to in Eclipse; and in a future episode, how you can define your own extension points for others to contribute towards.

If you have any comments or questions, please post them here.