Home > Eclipse development, Software Development, Testing > Writing an Eclipse Plug-in (Part 1)- What I’m going to do

Writing an Eclipse Plug-in (Part 1)- What I’m going to do

(The next few posts are a cheat. I have been slowly amassing these blogs for the last few weeks/months.)

So you want to write an Eclipse plug-in and don’t know where to start? Join the crowd. I wrote a great book on Eclipse (well, at least I liked it) and still find myself at a loss when it comes to implementing a standard feature set of functionality within a plug-in (sample chapters here).

I am going to document (read: heavily edit) what I did to implement a plug-in I am building to relearn all the things I wrote about in my book, but never really got a chance to use in this ever changing economy.

This blog will act as my requirements document as well as my FAQ. This way, when I forget how I did something I can just come here.

Where to Start?

Let’s say I have a software tool that is in desperate need of an IDE to help automate a number of silly tasks. That means a few things:

  • I want to aggregate the tasks
  • I want to aggregate any files involved in configuring the tool
  • I want to aggregate any source code involved in extending the tool

In addition, I want to use Mylyn to help me keep track of my tasks.

The list of things that can be done in Eclipse can be rather daunting. At a high-level this plug-in needs to accomplish a stardard list of things:

  • Create a project
  • Create some custom format XML files
  • Manage files within the project
  • Edit some XML files using a form-based approach rather than just editing the XML directly
  • Deploy files to a target directory

When it comes to adding functionality the best place to start is with use cases. Here are the ones I used:

  • Create a custom project
  • Edit a custom XML file
  • Deploy the files
  • Monitor how the deployed files have affected

The actor for all of the use cases will be a developer.

Create a custom project

The steps to create the custom project will be:

  1. Open the New Wizard dialog.
  2. Open the Custom Project folder
  3. Select the Custom Project item
  4. Press Next
  5. Enter the name of the project and a location in which to put it
  6. Press Finish
  7. A custom perspective will open

The custom perspective that will only display projects of my type. The project will contain custom categories where files will be displayed. The physical location of the files and the displayed location of the files in the navigator will be different. For example, the files may be located in:


The custom navigator will display the files in an almost flat structure:
My Project
  Category 1
  Category 2
  Category 3

If the user wants to see the actual folder structure they can look at the project in the Navigator view.

The custom perspective will display:

  • A custom navigator
  • The Navigator view
  • The Outline view
  • A log file view
  • Some yet-to-be-announced views
  • Editors as appropriate

The custom navigator will display individual images next to the workspace, project, categories and various file types that are displayed.

The custom navigator will allow the standard Eclipse behaviors from a popup:

  • Cut/copy/paste
  • Rename
  • Refresh
  • Workspaces
  • New
  • Project
  • Other

Edit a Custom XML file

There are a few XML files that need to be edited in a consistent and reliable way. The user will interact with a custom editor that will let them modify the XML file through a form or as XML text. The editor will have multiple form pages and one text page for direct XML editing.

Deploy the files

Once the files are in place, copy the files to the proper locations in the target software.

Right-click on the workspace or project will deploy the entire project.
Right-click on a particular category will deploy only the contents of that category
Right-click on a particular file will deploy just that file

In Addition

The above is all well and good, but the plug-in should also adhere to best practices whenever possible and that includes testing, putting strings in separate property files and flagging other strings as ignorable, caching images and disposing them.

What about testing? Testing is certainly interesting in the development of an Eclipse plug-in. The Eclipse Plug-ins book explains how to test a plug-ins, but there are a few things to bear in mind when testing anything:

  • Don’t test the platform
  • Test new functionality
  • Test before fixing a bug

I don’t enjoy having to change the API of a class to support testing, but sometimes there aren’t a lot of ways to test an API without retrofitting Eclipse to support dependency injection.

Therefore I will not be writing tests when creating Wizards or perspectives, but I will be writing tests on the behavior that the various GUI components will execute when they are told to do something. For example, the GUI flow for the use case Create A Custom Project will consist of:

  • Opening the New Wizard dialog
  • Displaying one or more Wizard pages
  • Clicking Finish causes the custom perspective to open
  • Clicking Cancel leaves everything the way it was

The flow, as a first phase of implementation, can work with little or no code. Whatever code needs to be written will just be glue code. Once those pieces come together then behavior can be written:

  • Create a custom project
  • Display the custom project in a custom navigator

Bear in mind that the Eclipse Plug-in Wizard has a number of templates that you can select from to create most of what you need to implement the first phase of a plug-in. The problem is that some of the things I needed were not there so I thought it better to assemble it piece by piece and blog about it.

Sorry for all the talking and not implementing anything. And BTW, I might never finish. Hope that is not a problem.

  1. Subbarao
    December 13, 2010 at 4:58 am


    This is a wonderful tutorial and I found it very helpful. Thanks very much for putting this tutorial on the web.

    I am designing a plugin using Managed Build System. Presently facing following problem.

    I have a tool which generates a folder and some files inside it. One file is of type C in that folder. So all I want a subdirs.mk with following content. I did not find suitable method to create a plugin, which can generate following rules.

    OUT_DIR/abc.c : xyz.rpk
    my-tool -rpk-dir OUT_DIR $<

    obj/abc.o : OUT_DIR/abc.c
    my-cc -o $@ $<

    Can you please help in the regard.


  2. Wishper
    December 15, 2011 at 4:04 am

    Thank you for this inspiring tutorial. I wonder if it is finished, because I never seen the ‘The End’ word, but it is passed nearly a year from your latest post.

    I was looking about the custom XML editor, because I never managed to understand how to add custom pages to the default SSE editor (any tips in this direction would be greatly appreciated!)

    Many thanks for all this series!

    • cvalcarcel
      December 31, 2011 at 2:19 pm

      The tutorial is not finished; I have found that I don’t have as much time available to work on it as I used to. I hope to get back to it, but I suspect I will be be unable/unwilling to.

      Thank you for the kind words!

  3. Mat
    July 17, 2012 at 11:31 am

    is this working for an RCP application?

  4. Pyraman
    April 19, 2016 at 10:05 pm

    The tutorial is great! I love it. 🙂
    But It will be better if you provided image/screenshot along with steps you described.


  1. February 12, 2013 at 10:17 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: