May 28, 2020
Hot Topics:

Developing Eclipse Plug-ins

  • By Peter Nehrer
  • Send Email »
  • More Articles »

With the ever-increasing popularity of Eclipse as an IDE as well as the Rich Client Platform, many companies and individuals are getting into the business of developing Eclipse plug-ins. Have you ever wondered what it would take to write one yourself? This installment of my Eclipse series will take you through the process of developing a simple visual plug-in. This will give you an opportunity to learn about the fundamentals of Eclipse plug-in architecture and become familiar with the Plug-in Development Environment (PDE).


Several years ago, when I first took a closer look at Eclipse (it was at version 2.0 at the time, as I recall), I was quite impressed by the fact that it was all available for free. It provided decent Java development capabilities, but nothing far above and beyond what was commercially available at the time. However, Eclipse really captured my interest when I discovered that I could easily extend its features with my own code. In fact, no privileged access or special tools were needed—Eclipse provided all tools and frameworks that were used in its own development. (Over the years I have come to believe that this recursive property is the hallmark of many clever frameworks and solutions in general).

Since then, Eclipse matured in all aspects—its design further improved, its architecture became more robust yet flexible, and its tools grew more powerful and effective. From what was initially a tool integration framework became a platform for arbitrary rich-client applications. However, the fact that the fundamental ideas behind Eclipse remain largely the same is in my mind a testament to the quality of its original design.

Extending Eclipse requires some basic understanding of its architecture and tools that are at your disposal. Because the easiest way to learn how to do something is to try doing it yourself, this article will help you develop a simple Eclipse plug-in using the tools provided by the Plug-in Development Environment. After getting a little background information on Eclipse architecture, you will use a PDE wizard to create a new plug-in, implement a simple workbench view, and test-run your work to see the results. The details of the implementation will be left for another installment. To accomplish this task, all you will need is a working installation of the latest Eclipse SDK (version 3.1). Visit http://www.eclipse.org/downloads to obtain a free copy.

Everything Is a Plug-in

From a developer's perspective, Eclipse is a platform for building a variety of client applications. While originally targeting development tools, the scope of Eclipse has widened to include ordinary rich-client applications, as well as non-desktop environments, such as hand-held devices and embedded systems. In order to support such a broad range of applications, a high degree of extensibility is necessary. Every Eclipse-based application consists of multiple components, called plug-ins, that interact with one another through a set of well-defined interfaces. Plug-ins are managed by a small run-time layer responsible for their discovery and activation. Starting with version 3.0, the original implementation of this layer was replaced by one based on the Open Services Gateway initiative (OSGi), thus improving Eclipse's portability across many hardware and operating system platforms and providing compatibility with a range of managed execution environments. As a result, Eclipse plug-ins are now implemented as OSGi bundles.

Similarly to other managed-component environments, the run-time characteristics of each Eclipse plug-in are specified in its descriptor, which is used by the run-time layer to configure the plug-in's execution environment. Prior to version 3.0, this descriptor was an XML-based file called plugin.xml, located at the root of the plug-in's directory. As a result of migrating to the OSGi run-time, plug-ins are typically packaged as JAR files and many of their properties, such as the unique identifier, version number, run-time classpath, and exported packages, are included in their JAR manifests (in other words, META-INF/MANIFEST.MF). However, a set of descriptor properties unique to Eclipse plug-ins—plug-in Extensions and Extension Points—remain in the plugin.xml file.

A plug-in's Extension Points are basically its component configuration points described using a subset of the XML Schema. A plug-in that implements a certain abstraction, such as displaying arbitrary views in the workbench, would publish an Extension Point specifying what each implementation needs to fulfill in order to be usable by this plug-in. These requirements typically include simple properties, such as window titles and icon paths, but also names of classes implementing specific interfaces. In this example, any plug-in wanting to provide a view implementation must do so by declaring an Extension of the Extension Point with ID org.eclipse.ui.views in its plug-in descriptor. This Extension must specify the name of a class implementing interface org.eclipse.ui.IViewPart. At run-time, the workbench plug-in searches the plug-in registry for all org.eclipse.ui.views Extensions and offers them to the user as displayable views. When the user chooses to open a particular view, the workbench plug-in instantiates the view's implementation class, specified in its plug-in descriptor, and interacts with it through interface org.eclipse.ui.IViewPart. This mechanism is the cornerstone of Eclipse's extensibility; plug-ins provide concrete implementations of other plug-ins' abstractions, and many in turn implement their own, higher-order abstractions and expose them as Extension Points for others to fulfill.

Listing 1: Contents of plugin.xml:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>

The Plug-in Development Environment

As you can see, the core task of developing Eclipse applications essentially consists of creating plug-ins that implement one or more Extensions. Theoretically, there's nothing stopping you from using Notepad, or vi, and javac on the command-line to develop Eclipse plug-ins (but I want to hear from anyone who's actually tried!). Luckily, Eclipse comes with a robust set of tools that make this job much easier. The Plug-in Development Environment (PDE) is freely distributed as part of the Eclipse SDK, and serves as a good example of an Eclipse-based IDE tool—it is nothing more than a set of plug-ins with their Extensions (as a matter of fact, they also expose several Extension Points, which you may use to develop your own PDE extensions).

In PDE, each plug-in under development is represented by a single Java project. Plug-in projects have certain unique characteristics that make them what they are; for example, each has a plug-in descriptor (a manifest and/or a plugin.xml file), a dynamic classpath based on dependencies specified in the descriptor, special builders, and other configuration properties. PDE provides a plug-in creation wizard that creates plug-in projects populated with the required essentials.

PDE comes with a special multi-page editor that makes plug-in development easier. The Plug-in Manifest Editor actually spans three files—the bundle manifest (META-INF/MANIFEST.MF), plugin.xml, and build.properties. It allows you to edit all properties necessary to describe a plug-in—ts basic run-time requirements, dependencies, extensions, extension points, and so on. You will take a more detailed tour of this editor while developing the sample plug-in.

Because Eclipse plug-ins are essentially Java projects, they are built incrementally by default, and no special manual build steps are necessary. However, PDE makes it possible to create unattended builds using Ant; you can create an Ant build script for your plug-in (in Package Explorer, right-click your plugin.xml and choose PDE Tools -> Create Ant Build File), which provides targets for creating various build outputs (such as plug-in JARs, source archives, and so forth).

To test-run your work, PDE provides a special launch configuration type that allows you to launch another workbench instance (referred to as the run-time workbench) with your workspace plug-ins included in its configuration (this is also referred to as self-hosting—you don't have to install your plug-ins into an external workbench just to test-run them; instead, you can use your own development workbench installation, dynamically). Your Eclipse launch configuration will allow you to specify which plug-ins you want included, special command-line arguments, environment properties, and so on.

PDE also comes with a solid user documentation, as well as extensive reference information (Javadoc and Extension Point documentation). Because it is released under the same terms as Eclipse itself, its source code is freely available and in fact included by default with the SDK.

Creating a Simple Plug-in

To get a better idea of how to develop plug-ins using PDE, you will create a simple workbench view. Its purpose will be to list all views available in the workbench at run-time (thus, you will call it the Superview). While doing so, you will examine the various parts of the Plug-in Manifest Editor, using the example at hand.

To get started, launch your Eclipse SDK and choose an empty workspace. When you close the Welcome page, you should find yourself in the Java perspective, by default (however, it is not required that you are in the Java perspective in order to proceed). First, you will use the New Plug-in wizard to create the plug-in. Then, you will edit its descriptor using the Plug-in Manifest Editor, and implement a Java class using JDT. Lastly, you will launch our plug-in in a run-time workbench to see the results. Now, get started:

  1. In the main menu, click File -> New -> Project, then select Plug-in Project and click Next.
  2. On the next wizard page, enter com.developer.superview as the Project name. Click Next.
  3. On this page, leave all fields with their default values and just click Finish. Answer yes when asked whether to switch to the Plug-in Development perspective. At this point, the plug-in has been created and you should see the Overview page of the Plug-in Manifest Editor.

The Overview page contains some general properties, such as the ID of your plug-in, its version, name, provider, plug-in class, and platform filter. It also provides links to pages for specifying plug-in content, its build configuration, as well as links for test-running and exporting the plug-in (all with brief descriptions). The ID is required and must uniquely identify your plug-in, globally. The Version is typically a three- or four-part, dot-separated version identifier (major.minor.service{.qualifier}). Plug-in versioning is documented in detail in your Platform Plug-in Developer Guide; in this exercise, you will settle for the default 1.0.0. The Name and Provider are optional and are only used as display labels in product configuration. The Class property is also optional, and for now it'll suffice to say that it represents a singleton instance of the plug-in at run-time, typically used as a single point of access to various plug-in-specific data. In this example, the wizard generates a default implementation of this class for you, but you will not reference it from any code developed in this example. Platform filter can be used to restrict the plug-in's platform applicability (not used in this example).

Page 1 of 3

This article was originally published on September 29, 2005

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date