CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Flint Brenton, Elizabeth White, Liz McMillan, Pat Romanski, Stackify Blog

Related Topics: OSGi, Eclipse Platform, Continuous Integration

OSGi: Article

Field Report on the Development of Commercial Plug-ins for Eclipse

Innovations Rule Technology

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.

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 (3) View Comments

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.


Most Recent Comments
SYS-CON India News Desk 06/03/06 12:42:37 PM EDT

The Eclipse runtime underwent a paradigm change in the transition from version 2.1 to 3.0. The OSGi framework specification R3.0 was implemented. Parts of the Public API have changed in version 3.0. Version 3.0 contains a compatibility layer to give plug-ins written for the 2.1 API the ability to run. However, for better performance and extra functionality it is strongly recommended that makers of plug-ins wean themselves as soon as possible from dependency on the compatibility layer.

Eclipse News Desk 06/03/06 12:16:14 PM EDT

The Eclipse runtime underwent a paradigm change in the transition from version 2.1 to 3.0. The OSGi framework specification R3.0 was implemented. Parts of the Public API have changed in version 3.0. Version 3.0 contains a compatibility layer to give plug-ins written for the 2.1 API the ability to run. However, for better performance and extra functionality it is strongly recommended that makers of plug-ins wean themselves as soon as possible from dependency on the compatibility layer.

Eclipse News Desk 01/14/06 05:01:00 PM EST

The Eclipse runtime underwent a paradigm change in the transition from version 2.1 to 3.0. The OSGi framework specification R3.0 was implemented. Parts of the Public API have changed in version 3.0. Version 3.0 contains a compatibility layer to give plug-ins written for the 2.1 API the ability to run. However, for better performance and extra functionality it is strongly recommended that makers of plug-ins wean themselves as soon as possible from dependency on the compatibility layer.