| By Caroline Buck |
Article Rating: |
|
| April 5, 2006 04:15 PM EDT |
Reads: |
23,945 |
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.
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 (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
Subscribe to Eclipse Developer's Journal Email News Alerts
Subscribe via RSS
