Plug-in Development 101: The Fundamentals

Modification

After completing the previous step, a new plug-in was created in the workspace. We're now presented with an editor (see Figure 5) to help us work with the fresh plug-in. The first page in the editor we see is the Overview page, which contains modifiable plug-in identifier information with sections describing the various items you can edit within our plug-in. For example, we see the identifier (ID) and version fields we previously defined using the template shown in Figure 4.

Figure 5: Plug-in Editor (Overview Page)

Extensions and Extension Points

The next step on our plug-in adventure involves adding an extension. However, before we dive into the details, let's first understand two important topics when developing extensible Eclipse plug-ins: extensions and extension points. Using a simple analogy, you can think of an extension as a plug and an extension point as a socket. Each extension point is unique and defines a contract to be adhered to. For example, Eclipse ships with an org.eclipse.ui.editors extension point (socket) that allows you to supply our own editor (the plug).

In our case, we'll create a new extension that contributes to the Eclipse toolbar. To accomplish this, we will use a template (similar in concept to the template we used to create our plug-in) for the org.eclipse.ui.actionSets extension point. From the Overview page in the plug-in editor, select the Extensions link in the Extension/Extension Point Content section. Click Add... and select the org.eclipse.ui.actionSets template (see Figure 6) with all the defaults filled in.

Figure 6: Extension Templates

Runtime

An important part of our plug-in is that it's self-describing. One of the things our plug-in must describe is what it offers the world. In the context of Eclipse, these are called exported packages. In our plug-in, we get to decide what packages we export so other plug-ins can peek inside those packages to see they depend on our plug-in. It's also possible to mark exported packages as being internal, which tells plug-in developers that we don't consider the package in question as API. To specify exported packages, we use the Runtime page within the manifest editor.

Figure 7: Runtime Page

Dependencies

In the previous section, we described what a plug-in must do to expose its functionality to the world. Imagine you are a different plug-in and wanted to use the aforementioned functionality. How would you express your interest in doing so? In the context of Eclipse, these are called dependencies. In the simplest case, plug-ins can depend on other plug-ins. For example, if you want to build your own editor in Eclipse, you would need to depend on the org.eclipse.ui.editors plug-in. To specify dependencies, you have to be on the Dependencies page of the plug-in editor.

Figure 8: Dependencies Page

Note that on top of depending on individual plug-ins, you can choose to depend on packages that are exported from plug-ins (see the Imported Packages section on the Dependencies page). This is more of an advanced topic and useful when you don't want to tie your plug-in to a specific implementation. For example, imagine depending on a package com.company.xml.parser that supplied an XML parser. Now picture having two plug-ins like com.company.xml.parser.mobile and com.company.xml.parser.desktop that provided two different implementations of the same XML parser, but for different environments.

Source Editors 

The Runtime and Dependencies pages are just visual representations of what is specified mainly in MANIFEST.MF file. For advanced users wishing to edit the source of this file by hand, PDE offers a source editor with code completion for the various headers found in a plug-in manifest definition.

Figure 9: Source Editing