• Language Toolkit: Extension points that support refactoring.
• Other: Provides access to the underlying Ant infrastructure. Facilities include read-only content viewers and specialized search pages.
The Platform Plug-in Developer Guide in the Eclipse online documentation provides a thorough description of all the extension points and this is, in fact, the best place to get familiar with what the various extension points represent.
Extensions in turn provide the additional functionality that plugs into the extension points. This is what plug-ins generally do. They extend Eclipse functionality by “plugging in” to extension points.
7.2.2 MANIFEST.MF and plugin.xml
In Eclipse terminology, plug-ins are defined by two files, MANIFEST.MF and plugin.xml. The MANIFEST.MF file identifies the plug-in by name, version, and so on. The plugin.xml file defines the extensions and extension points that this plug-in provides. This is how the plug-in gets linked into the Eclipse platform environment.
Ultimately, MANIFEST.MF and plugin.xml get packaged along with the Java code in a Java archive (.jar) file.
7.2.3 Naming Conventions
You’ve probably noticed by now that all of the Eclipse plug-ins have rather long names of the form org.eclipse.<feature>.<element of feature>_<number that looks like a version><maybe another big long number>.jar. This is a naming convention that assures that all Java packages, or in this case Eclipse plug-ins, are unique. Eclipse requires that all plug-ins have a name that is unique throughout the world.
The name begins with a top-level Internet domain, such as .com, .org, .edu, etc., or one of the two-letter codes that identify a country outside the United States. The next element is a domain name representing the organization that wrote and/or maintains the package. Subsequent components of the name are specified by the organization and may include elements such as division, department, project, and so on.
For Eclipse the next component of the name is a component such as core, ui, or debug, or a subproject such as cdt, jtk, or pde. This is usually followed by the element of the component or subproject. Then comes the underscore followed by a version number. This is followed by another underscore, a “v”, and the date the package was built.
The convention further suggests that the Eclipse project name should match the plug-in name up to the first underscore.
7.3 Our First Plug-In
As a way to get started with writing plug-ins, we’ll create a simple workbench view that just lists all views available in the workbench at run-time. You might think of it as a “super view” so that’s what we’ll call it: SuperView. While it doesn’t really do a lot, it does illustrate most of the basic principles involved in using PDE.
7.3.1 Creating a Plug-In Project
Like every other project, building a plug-in starts by creating a project. Select File→New Project. Find and expand the Plug-in Development category and select Plug-in Project as shown in Figure 7.1.
Figure 7.1: Project selection wizard.
This brings up the dialog shown in Figure 7.2. Again, like every other project, we have to give it a name. In accordance with the Java naming standard, let’s call it com.eclipsebook.superview. There is also an option to choose a target platform, which simply means whether we’re targeting a version of Eclipse, or an OSGi framework like Equinox. In this case, we’ll stick with the 3.4 version of Eclipse to keep things simple.
Figure 7.2: Plug-in new project dialog.
The next screen (Figure 7.3), called Plug-in Content, basically identifies the plug-in in the form of properties, and says something about its content. The properties are structured to make the plug-in compliant with Eclipse. All the default values are suitable.
Figure 7.3: Plug-in Content dialog.
The Plug-in ID represents a unique identifier for your plug-in. No other plug-in can share the same identifier. Note that the default value for the ID is the same as the name we used in the previous screen. The Plug-in Version consists of four segments (three integers and a string) respectively named major.minor.service.qualifier. The Plug-in Name is simply a human-readable name. Likewise, the Plug-in Provider is a human-readable string identifying the author of the plug-in, which defaults to the organization field of the name.
There’s an option to generate a plug-in activator, which is simply a class that controls the life cycle of a plug-in; basically a start and stop method. The activator is usually responsible for setting up things and for properly disposing of resources when the plug-in isn’t needed anymore. We’ll also say here that this plug-in makes contributions to the UI.
Click Finish. If you’re not in the Plug-in Development environment, Eclipse will prompt you to switch to it.
PDE has created a template project for our new plug-in. Views initially visible in the Plug-in Development Perspective include:
• Package Explorer: The Java equivalent of the Project Explorer in CDT. It shows the contents of our new Hello World project.
• Plug-ins: Lists all of the plug-ins presently installed in Eclipse. You can select a plug-in and open it in the…
• Manifest Editor: A form-based multi-page editor that aids in the creation of the plugin.xml and MANIFEST.MF files.
• Outline: As in CDT, this view organizes the information in the Manifest Editor in an easily browsable structure.
7.3.2 Plug-In Content
The Manifest Editor initially shows an overview as seen in Figure 7.4. This essentially duplicates the information entered in the Plug-in Content dialog and also includes links to several other tabs in the Manifest Editor and related functionality. Our plug-in will create a new extension that contributes to the Eclipse toolbar and also adds an item to the main menu.
Figure 7.4: Manifest Editor overview tab.
The Dependencies tab specifies what plug-ins and packages this plug-in depends on. Initially the Required Plug-ins list has two entries: org.eclipse.ui and org.eclipse.core.runtime. Just about everything is dependent on these two.
The Imported Packages list lets you specify packages that your plug-in depends on without identifying the plug-in that contains the package.
Packages are a useful way to specify implementation-independent behavior. Suppose, for example, that your plug-in is dependent on an XML parser. We can implement that parser as a package called com.company.xml.parser. You could then create two plug-ins, say, com.company.xml.parser.mobile and com.company.xml.parser.desktop, each of which implements the same parser package — that is, the same extension points, but for a different environment.
Click the Runtime tab in the Manifest Editor, or click Runtime under Plug-in Content in the Overview form. This lets us specify which packages contained in the plug-in will be made visible to other plug-ins. Any packages not explicitly exported will not be visible externally. Click Add… to see that our plug-in has one package available for export. We don’t really need to export the package, but it doesn’t hurt, so go ahead and select it, and click OK. Now click on the package in the Exported Packages list. The Properties… button lets you set a version for that package.