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?

As we enter 2006, there’s nothing stopping the spread of Eclipse, the open source development environment. The steadily growing number of free and commercial plug-ins available attests to its success. It’s now time to report on our experiences in developing the visual rules plug-in for Eclipse. Caroline Buck (pictured) shows you how to steer clear of the pitfalls in development.

The core idea of Innovations rule technology consists of two components: the graphical modeling of business logic and the generation of executable program code from the models. At the end of 2002 we decided to redesign our rule system. It was quickly apparent that the existing Java applications for modeling and for code generation should become an Eclipse plug-in or a whole range of Eclipse plug-ins.

Experiences with the more monolithic architecture components up to that time led us to the following realization: The new product must be based on a foundation that is above all easy to extend. In addition, our customer projects showed that the tool had already found favor on the part of users with little programming know-how. However, the product was seen less as a software development tool, although we ourselves used it as one. At the same time Eclipse had long become established as the Java development environment at Innovations. The implementation of our rule technology as a module for this attractive IDE practically thrust itself upon us.

A new name for the business logic tool was quickly found: visual rules. At the beginning of product development considerations were made on how to best split up the plug-ins from which visual rules was to be composed. Because the Eclipse platform itself makes excessive use of its plug-in concept, it offered a very good orientation guide on segmentation.
Java code generator
UI components, e.g. properties
Abstract code generator
Basic functionalities, EMF models
Online help
Ready-made rule set examples
Interfaces such as Rulet Editor and Rule Tree Editor
Product design (branding) such as splash screen, licensing information
Third-party software: XML parser
Table 1: visual rules 1.0 plug-ins

The first release of visual rules for Eclipse 2.1 from January 2004 consisted of ten plug-ins (see Table 1), bundled into one feature. 21 months or approx. six person years later the current product version contains 48 plug-ins split across four features. The base is formed by the graphical modeling client. Extra features are the Java code generator, the COBOL code generator and DB Connectivity for direct database access from rule sets.

Ideally, each feature can be installed separately from the others. However, dependencies with one another cannot always be avoided. Thus, the DB Connectivity extension for the visual rules platform, for example, requires the Java code generator. These dependencies (version and name of required plug-ins and features plus Eclipse platform) are declared in the feature manifest, which is then interpreted by Eclipse to support installation.

Common Code Base?
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.

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.

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.

See next page for What Makes a Good Plug-in?| Tips & Tricks | Future Outlook

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.