Page 2 of 3   « previous page   next page »

This is why we didn’t even attempt to create a common code base for the visual rules plug-in for Eclipse 2.1 and the current 3.x versions. There were just too many dependencies, especially to the org.eclipse.ui plug-in. This is why a redesign of the central rule data definition editor was carried out during visual rules plug-in migration. We replaced this editor with a special visual rules Navigator. This new view is based on the Resource Navigator and displays – similar to the JDT Package Explorer – all project settings and items as a tree. All rule project settings can also be edited here.
A major release was issued at the end of development and the version number jumped from 1.x to 3.0. Currently the version numbers of our plug-ins and Eclipse in sync.

>>buck_visualrules_1.tif<<
Figure 1: Segmentation of the Debugger plug-in

Our current code base supports both Eclipse 3.0 and 3.1. Each plug-in now has “internal” packages containing all classes that may only be called within the plug-in (Internal API) (Figure 1). Starting with Eclipse 3.1 internal packages are automatically hidden. This mechanism requires strict conformance to recommended naming conventions.

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.

Page 2 of 3   « previous page   next page »