Open Development Platform

Eclipse Platform

Subscribe to Eclipse Platform: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Eclipse Platform: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Eclipse Platform Authors: Janakiram MSV, Ken Fogel, Marcin Warpechowski, Michael Meiner, Liz McMillan

Related Topics: OSGi, Eclipse Platform, Continuous Integration

OSGi: Article

Commercial Plug-ins for Eclipse: A Field Report on Avoiding Development Pitfalls

Workspace – The Final Frontier?

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.

Tips & Tricks
·          The prime imperative is to break things down into the smallest components in order to keep dependencies between individual plug-ins at a minimum. Dependencies should focus on the core plug-in. Not abiding by this premise in the subsequent definition of features can, in extreme cases, result in the need for comprehensive refactoring.

·          Starting with version 3.0, popular direct access to useful, but unfortunately internal functions of Eclipse or other plug-ins (even your own!) is taboo. Furthermore, no code can be copied to internal classes as a workaround if it uses internal classes itself.
·          Consistently remove old code in order to reduce dependencies on the compatibility layer.
·          Take internationalization, i.e. releasing the software in multiple languages, into account from the beginning.
·          Always use the platform to modify project resources. This avoids problems associated with synchronization, e.g. dirty flag display.
·          Do not change the CVS to watch/edit mode. The PDE can’t handle write-protected local copies.
·          For seamless installation via the update site the versions of the configuration files (plug-in and feature) must match.
Table 2: Tips and Tricks for plug-in developers
Always Multi-Language!
visual rules rule technology has always been released in two languages – German and English. All texts were therefore entered in the files. We recommend properly documenting or naming the keys used and not using them compiled, primarily in order to find your way around in complex language files. For the same reason, messages should not be compiled in program code, but rather defined in Java message format.

The labels of input fields have to contain mnemonics in order for the plug-in to be completely controllable from the keyboard. To do this, a & character is placed in front of the hot key you want. By the way, labels can also be stored in multiple languages in the plug-in, manifest and feature files. The keys within these files can be accessed by using their names with the % character as a prefix. In addition, the visual rules language files intended for displaying text in the Eclipse interface is converted to Unicode before being released. You should take these tips to heart at the beginning of plug-in development so you can easily add other languages to your plug-in.

Different Release Concepts
We currently release visual rules in three variations: The Eclipse plug-in is intended for developers wanting to add our product to an existing IDE installation. They can get the latest version from the update site, Problems sometimes occur with the update site if the target platform lies behind a particularly airtight firewall. This is why a zip file is available from the product web site, to be extracted into the Eclipse root directory after download.

visual rules is provided as a self-executing Exe file for easy installation as a stand-alone product with an Eclipse runtime environment adapted to the product design. The target group here are developers and expert users that have not previously worked with Eclipse. For WebSphere developers visual rules is also available for download as a certified WebSphere plug-in. However, this product variation is still at version 1.2.6, because WebSphere Application Developer is based on Eclipse 2.1.

Figure 2: The visual rules build process
All product variations are the result of our build process (Figure 3) that is carried out once an hour if a modified source file is checked into the repository beforehand. A build currently lasts approx. 50 minutes. To ensure that all current sources are actually recompiled, a “clean build” is carried out instead of an incremental build. Afterwards diverse tests are carried out.

We use JUnit plug-in tests throughout, but which can also run as simple JUnit tests, particularly the tests for the code generators. This makes sense, because every true JUnit plug-in test starts its own Eclipse instance. In total these tests offer relatively poor performance because of this. We also integrate our autotest projects – a range of visual rules projects automatically built and executed by Ant – via a JUnit test that calls this Ant script.

User interface tests are a hot potato – here you should first of all decide on a tool or an approach. Because a UI whose code consists of anonymous components can only be made testable with great difficulty later on, the “hooks” for automated tests must be implemented from the very beginning.

All visual rules variations require a valid license at runtime. To evaluate out plug-in a request can be made on our web site for a free 30-day license, which is automatically sent via e-mail. All license files contain properties that are verified by the de.innovations.visualrules.license plug-in: This includes a comma-separated list of plug-in names that may be executed by the user, the type of license, the validity period, the name and e-mail address of the licensee and a digital signature preventing manipulation of licensing information.

Coding guidelines
Checkstyle (
Properties Editor for Unicode
Propedit (
Continuous Integration
Cruise Control (
Installation software
Nullsoft Scriptable Install System (
Docbook (
Table 3: Tool Time – Tools we use for development and release of visual rules

Future Outlook
The development of our product is of course continuing. For the coming version we would like to make all visual rules actions and functions accessible to other plug-ins via extension points. In doing so, we will continue to keep an eye focused on segmenting the plug-ins. Future planning also entails implementing specific editors as RCP (Rich Client Platform) applications.

Links & references
[1] Scott Fairbrother, Pat McCarthy, Dan Kehn: The Java Developers Guide to Eclipse, Addison-Wesley, 2004
[2] Eric Clayberg, Dan Rubel: Eclipse Building Commercial Quality Plug-ins, Addison-Wesley, 2004
[3] John Arthorne, Chris Laffra: Official Eclipse 3.0 FAQs, Addison-Wesley, 2004

More Stories By Caroline Buck

After gaining seven years of application development experience in the industry and service sector, at Innovations Softwaretechnologie GmbH, Caroline Buck is now responsible for technology marketing of the visual rules Eclipse plug-in.
She completed her studies of Information Management at the University of Cooperative Education Ravensburg in 1997. She has spoken at various academic events and at CeBIT on topics concerning information distribution and business rules.

Comments (2)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.