Welcome!

Eclipse Authors: RealWire News Distribution, Adam Blum, Aditya Banerjee, Jeff Anders, CJ Fearnley

Related Topics: Eclipse

Eclipse: Article

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

Innovations Rule Technology
By Caroline Buck
Article Rating:
June 3, 2006 01:00 PM EDT
Reads:
 7,498
Workspace – the final frontier? This is the year 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. We'll show you how to steer clear of development pitfalls.

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.
 
Plug-in
Description
de.innovations.visualrules.builder.java_0.9.2.jar
Java code generator
UI components, e.g. properties
de.innovations.visualrules.builder_1.0.0.jar
Abstract code generator
de.innovations.visualrules.core_1.0.0.jar
Basic functionalities, EMF models
de.innovations.visualrules.doc_1.0.0.jar
Online help
de.innovations.visualrules.examples_1.0.0.jar
Ready-made rule set examples
de.innovations.visualrules.launcher.java.test_0.9.2.jar
Launcher
de.innovations.visualrules.monitor_0.9.2.jar
Monitoring
de.innovations.visualrules.ui_1.0.0.jar
Interfaces such as Rulet Editor and Rule Tree Editor
de.innovations.visualrules_1.0.0.jar
Product design (branding) such as splash screen, licensing information
de.innovations.visualrules.xalan_1.0.0.jar
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 (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.

Published June 3, 2006 – Reads 7,498
Copyright © 2006 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

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.