Skip to content

Tag: Extension Points

Extending and Modifying Eclipse – The Basics

This post is written for a team of students with which I am developing a meta-modeling platform based on the OPM modeling methodology and the OPM editor I am implementing. And since I am already creating the knowledge, why not share it with everyone else. So here it is.

The eclipse IDE, which I think is the most popular Java IDE today, is not only an IDE but a full application platform. The IDE is actually an RCP (Rich Client Application) written for the eclipse platform. So how does it work? Let’s see a schematic representation of the IDE:

source: http://www.ibm.com/developerworks/opensource/library/os-ecjdt/fig2.jpg (This image is from 2003, but things have not changed that much)

Behind all the eclipse platform runs the Platform Runtime (something called an OSGi runtime, of which I don’t have much knowledge), which consists of basic capabilities, like basic editors, workspace browsers and things like that. This runtime exhibits to the programmer something called “extension points”. An extension point is like an interface, and defines a set of attributes that you must implement in order to create an extension for this extension point. The Java editor is actually an implementation of the “editor” extension point that the platform exhibits. When the user wants to open a file that ends in “.java”, the platform know that his file should be opened with the editor defined in the extension point, and calls this editor using the contract defined in the extension point.

For example, let’s say you want to create a “New File Wizard” (which is the current tasks of the students). The platform has an extension point called “org.eclipse.ui.newWizards” for this purpose. In this extension point, you can define wizard categories, wizards and primary wizards (which is a reference to a wizard that should be used as the primary wizard in a product). Since in my OPM editor I have an EMF model that generated editor code, this also generates a “New File Wizard” for the model, so let’s see how this looks (this is a snapshot of the “Extensions” tab of the “MANIFEST.MF” file in the generated EMF editor project):

Here we define that the plugin implements the “newWizard” extension point, adding a new category called “Example EMF Model Creation Wizards” and a new wizard called “OPM Model”. Let’s dig a bit deeper to see how the wizard is defined:

BTW, this screenshots are of the Plug-In Development Environment plugin, which gives a nice GUI to develop eclipse plugins. All of what you see here is actually written in XML format in the plugin.xml file. The GUI is really good and completely manages all the plugin files (plugin.xml, MANIFEST.MF).

So going back to the extension definition. From the work I have done with eclipse, all extension that you implement must have an ID that must be unique. I guess there are a number of places that use this ID for something. Just make sure that every time you create an extension you give it a unique ID and things will probably be fine. Other not-much interesting fields are the name of the wizard (which is shown to the user. Note the %XXX notation, which means that the text is taken from a plugin.properties file. This is good for internationalization, so the text can be changed without having to recompile any code), the icon that is shown to the user with the wizard, and the name of the category to which the wizard is added (Oh! here we have a reference to a wizard by it’s ID. See? told you:-)). Last, but not least, is the class that actually implements the wizard. If you read the documentation of the extension point (or if you hover over the “class” link on the left of the text box), you will learn that this class must implement org.eclipse.ui.INewWizard. If this was a new plugin, clicking on the link would actually open a “New Java File” dialog with this interface already in the list of implemented interfaces.

From here on it is pure and simple Java (more or less). After doing this, you can add the plugin to an eclipse environment, and when it executes, it will load the extension and make it available to the user.

This was a very high level (30K feet as some say) overview of how eclipse is built. I’m pretty sure I missed a lot of details, but given this starting point there are many (and good) tutorials out there in the wild (I love Lars Vogel’s tutorials).

 

Enhanced by Zemanta