Eclipse Platform

What Makes a Good Plug-in?
A consistent appearance with structured, multi-language interface if possible, initially makes a good first impression. The UI Guidelines from Eclipse are the Bible for design and ensure seamless graphical integration into the development platform. In addition to its visual appearance, the interface also has to always show a response to user input. Speaking on behalf of all users: Nothing is more confusing than “you click and then nothing happens…”. Equally, all background processes must be visualized as a progress bar in the UI, including the option of terminating them if necessary.

Support for logging and tracing is essential for the stability of the plug-in. For this purpose a trace system is entered as a static method in the plug-in class of every plug-in. It is used within the other classes of the plug-in for debugging purposes. Tracing can easily be enabled in the launch configuration. For logging it’s best to use the Eclipse .log than your own log files. If absolutely required, logging must take place in the local Temp directory and never directly in the plug-in directory. They may be write-protected in multi-user installations! It is also better to save all configurations using the appropriate Eclipse mechanisms (dialog settings, preferences, memento, project description) and not create them by hand.

Changing Eclipse resources generally requires great care. You should make sure that changes are carried out in the background without interfering with other processes. Moreover, all markers (problem, task, bookmark, search., etc.) must be correctly updated and the progress shown in the UI. Resource change listeners should also be fast: In most cases termination can take place immediately for changes made only to markers.

If every developer implements a different approach to exception handling, sometimes exceptions will be thrown directly outside, sometimes packed together and then thrown outside, sometimes simply disappear, etc. Especially considering the many parallel processes running in Eclipse – each command corresponds to a small thread – exceptions like to go through the JVM and out again. It is more elegant if exceptions land at a central location with an attractive UI. The same applies to more complex editors with problem markers: In exception handling removing the marker is often overlooked. These then act extremely inflexibly and in the worst case can only be removed by clearing them or renaming the project. For this reason it is advantageous to create and clear markers at one central location.

Another tip for those using CVS to manage their source code: Because in every software project there are files that are hard to remember it might seem a good idea to turn on Watch/Edit mode. This sets the local copies of all files to read-only. Unfortunately, the write-protected files are blocked from being accessed by plug-ins and the PDE can’t handle them.