| By Caroline Buck |
Article Rating: |
|
| June 3, 2006 01:00 PM EDT |
Reads: |
10,334 |
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.
Subscribe to Eclipse Developer's Journal Email News Alerts
Subscribe via RSS
