Eclipse Plugin Development

The Eclipse platform is structured as a core runtime engine and a set of additional features that are installed as platform plug-ins. Plug-ins contribute functionality to the platform by contributing to pre-defined extension points. The workbench UI is contributed by one such plug-in. When you start up the workbench, you are not starting up a single Java program. You are activating a platform runtime which can dynamically discover registered plug-ins and start them as needed.

When you want to provide code that extends the platform, you do this by defining system extensions in your plug-in. The platform has a well-defined set of extension points - places where you can hook into the platform and contribute system behavior. From the platform’s perspective, your plug-in is no different than basic plug-ins like the resource management system or the workbench itself.

Eclipse Rich Client Platform

While the Eclipse platform is designed to serve as an open tools platform, it is architected so that its components could be re-used to build just about any client application. The minimal set of plug-ins needed to build a rich client application is collectively known as the Rich Client Platform.

But if you want to do an independent application, based on the Eclipse platform, then it is an RCP (“Rich Client Platform”).

Eclipse-based applications which are not primarily used as software development tools are called Eclipse RCP applications. An Eclipse 4 RCP application typically uses the base components of the Eclipse platform and adds additional application specific components.

Many people that have built, or are building, RCP applications state that the main value they get from using RCP is that it allows them to quickly build a professional-looking application, with native look-and-feel, on multiple platforms, allowing them to focus on their value-add. They appreciate that the components that form RCP are of high quality, are actively maintained, and are open source. They often discover after the initial adoption of RCP that there are many other Eclipse components available for reuse (e.g. Help UI, Update Manager, Cheat Sheets, Intro, etc.). Several have also discovered that the inherent extensibility of Eclipse allows them to build not only a closed-form product, but also an open-ended platform (like the Eclipse IDE) in their own domain.

What is an Eclipse product?

Strictly speaking, a product is an extension to the extension point called org.eclipse.core.runtime.products. The purpose of a product is to define application-specific branding on top of a configuration of Eclipse plug-ins. Minimally, a product defines the ID of the application it is associated with and provides a name, description, and unique ID of its own. A product also stores a table of additional properties, where the UI stores information such as the application window icon and the all-important blurb in the Help > About… dialog. It is quite possible to run Eclipse without a product, but if you want to customize the appearance of Eclipse for your particular application, you should define one.

Because more than one product can be installed at a given time, the main product is singled out in a special marker file called .eclipseproduct in the Eclipse install directory. This file denotes the name, ID, and version number of the main product that will be used. The product in turn is a plug-in in the plugins directory, which includes product branding elements, such as the splash screen and workbench window icons.

For more details, see the methods declared by the IProduct interface defined in the org.eclipse.core.runtime plug-in. IProductConstants in the org.eclipse.ui.workbench defines the keys of product properties that are of interest to Eclipse products having user interfaces.

What is an Eclipse application?

Technically, an Eclipse application is a plug-in that creates an extension for the extension point org.eclipse.core.runtime.applications. However, the extension point is fairly special. Only one application gets to run in a given Eclipse instance. This application is specified either on the command line or by the primary feature. After the platform starts up, control of the VM’s main thread is handed over to the application’s run method. The application’s entire lifecycle occurs within the scope of this method. When the run method returns, the platform shuts down.

The application is essentially the boss; it’s the Eclipse analog of the C or Java main method. All other plug-ins in the configuration plug into the application. What goes into the run method is entirely up to you. It can be a graphical application, which will create a user interface and run some kind of event loop, or a completely headless application that runs without interacting with a user.

Because a running Eclipse instance has only one application in it, the philosophy of building applications is very different from the approach when building plug-ins. Essentially, the flexibility given to plug-ins must be mitigated by the fact that other plug-ins in the system may have competing requirements. The laws of plug-in behavior are designed to allow plug-ins to interact in ways that do not impinge on the behavior of other plug-ins. Such constraints are not as important for the application, which can have the final say when the needs of various plug-ins don’t intersect. Whereas plug-ins are citizens of the Eclipse Platform, the application is king. For example, because the application is always started first, the lazy-loading principle doesn’t apply to it. The application can customize the menus and toolbars programmatically rather than using the various workbench extension points. The application can also determine whether views and editors have title bars and whether views can be closed or resized.

The Eclipse SDK is one particularly well-known example of an Eclipse application. To explore how it works, start by looking at the IDEApplication class in the org.eclipse.ui.ide plug-in.

What is the difference between a product and an application?

At first glance, the notions of product and application in Eclipse seem similar. Both are contributed via an extension point, and both are used to bring order to the chaos of an otherwise random collection of executing Eclipse plug-ins. However, the two concepts have some important differences.

  1. an application defines behavior, so it has code associated with it. A product on the other hand is purely declarative. That is, a product provides properties, such as icons and text, that are used to customize the appearance of a running application.

  2. A second distinction is that there is typically only one product, but that product may include several applications. For example, the Eclipse Platform is a single product but includes several applications, such as the workbench application and an application for running custom Ant build files. All applications under a given product have the same branding elements associated with them.

Plugin API tools

Click URL

Eclipse application model

The Eclipse platform uses an abstract description, called the application model, to describe the structure of an application. This application model contains the visual elements as well as some non-visual elements of the application.

The visual parts are, for example, windows, parts (views and editors), menus, toolbars, etc. Examples for non-visual components are handlers, commands and key bindings.

Each model element has attributes which describe its current state, e.g. the size and the position of a window. The application model also expresses the relationship of the model elements via a hierarchy.

The individual user interface widgets, which are displayed in a part, are not defined via the application model, e.g., the content of the part is still defined by your source code.

If the application model was a house, it would describe the available rooms (parts) and their arrangement (perspectives, part stacks, part sash containers (table)), but not the furniture of the rooms. This is illustrated by the following image.

Connecting model elements to classes and resources


Delta Pack to Features

In “Work With” type:

  1. Check “Eclipse RCP Target Components”
  2. Check “Equinox Target Components”

Running 3.x RCP applications on top of an e4 runtime

To migrate your Eclipse RCP application to e4 API you have to exchange the target platform to an Eclipse 4.x version.

The following features includes the necessary Eclipse platform plug-ins required for this.


Product id in Product Configuration must be consistent with id in RCP 3.x org.eclipse.core.runtime.product and RCP 4.x in .e4xmi

Product Application of RCP 3.x *prjectName*.rcp.applicaton and RCP 4.x org.eclipse.e4.ui.workbench.swt.E4application