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: Stackify Blog, Flint Brenton, Pat Romanski, Liz McMillan, Elizabeth White

Related Topics: OSGi, Eclipse Platform, Continuous Integration

OSGi: Article

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

Innovations Rule Technology

Changing Eclipse resources generally requires great care. You should make sure that changes are carried out in the background without interfering with other processes. Moreover, all markers (problem, task, bookmark, search., etc.) must be correctly updated and the progress shown in the UI. Resource change listeners should also be fast: In most cases termination can take place immediately for changes made only to markers.

If every developer implements a different approach to exception handling, sometimes exceptions will be thrown directly outside, sometimes packed together and then thrown outside, sometimes simply disappear, etc. Especially considering the many parallel processes running in Eclipse – each command corresponds to a small thread – exceptions like to go through the JVM and out again. It is more elegant if exceptions land at a central location with an attractive UI. The same applies to more complex editors with problem markers: In exception handling removing the marker is often overlooked. These then act extremely inflexibly and in the worst case can only be removed by clearing them or renaming the project. For this reason it is advantageous to create and clear markers at one central location.

Another tip for those using CVS to manage their source code: Because in every software project there are files that are hard to remember it might seem a good idea to turn on Watch/Edit mode. This sets the local copies of all files to read-only. Unfortunately, the write-protected files are blocked from being accessed by plug-ins and the PDE can’t handle them.

Tips & Tricks
· The prime imperative is to break things down into the smallest components in order to keep dependencies between individual plug-ins at a minimum. Dependencies should focus on the core plug-in. Not abiding by this premise in the subsequent definition of features can, in extreme cases, result in the need for comprehensive refactoring.
· Starting with version 3.0, popular direct access to useful, but unfortunately internal functions of Eclipse or other plug-ins (even your own!) is taboo. Furthermore, no code can be copied to internal classes as a workaround if it uses internal classes itself.
· Consistently remove old code in order to reduce dependencies on the compatibility layer.
· Take internationalization, i.e. releasing the software in multiple languages, into account from the beginning.
· Always use the platform to modify project resources. This avoids problems associated with synchronization, e.g. dirty flag display.
· Do not change the CVS to watch/edit mode. The PDE can’t handle write-protected local copies.
· For seamless installation via the update site the versions of the configuration files (plug-in and feature) must match.

Table 2: Tips and Tricks for plug-in developers


Always multi-language!
visual rules rule technology has always been released in two languages – German and English. All texts were therefore entered in the plug-in.properties files. We recommend properly documenting or naming the keys used and not using them compiled, primarily in order to find your way around in complex language files. For the same reason, messages should not be compiled in program code, but rather defined in Java message format.
The labels of input fields have to contain mnemonics in order for the plug-in to be completely controllable from the keyboard. To do this, a & character is placed in front of the hot key you want. By the way, labels can also be stored in multiple languages in the plug-in, manifest and feature files. The keys within these files can be accessed by using their names with the % character as a prefix. In addition, the visual rules language files intended for displaying text in the Eclipse interface is converted to Unicode before being released. You should take these tips to heart at the beginning of plug-in development so you can easily add other languages to your plug-in.

Different release concepts
We currently release visual rules in three variations: The Eclipse plug-in is intended for developers wanting to add our product to an existing IDE installation. They can get the latest version from the update site, www.download-visual-rules.de/updatesite. Problems sometimes occur with the update site if the target platform lies behind a particularly airtight firewall. This is why a zip file is available from the product web site, to be extracted into the Eclipse root directory after download.
visual rules is provided as a self-executing .exe file for easy installation as a stand-alone product with an Eclipse runtime environment adapted to the product design. The target group here are developers and expert users that have not previously worked with Eclipse. For WebSphere developers visual rules is also available for download as a certified WebSphere plug-in. However, this product variation is still at version 1.2.6, because WebSphere Application Developer is based on Eclipse 2.1.

>>buck_visualrules_2.tif<<
Figure 3: The visual rules build process

All product variations are the result of our build process (Figure 3) that is carried out once an hour if a modified source file is checked into the repository beforehand. A build currently lasts approx. 50 minutes. To ensure that all current sources are actually recompiled, a “clean build” is carried out instead of an incremental build. Afterwards diverse tests are carried out.
We use JUnit plug-in tests throughout, but which can also run as simple JUnit tests, particularly the tests for the code generators. This makes sense, because every true JUnit plug-in test starts its own Eclipse instance. In total these tests offer relatively poor performance because of this. We also integrate our autotest projects – a range of visual rules projects automatically built and executed by Ant – via a JUnit test that calls this Ant script.
User interface tests are a hot potato – here you should first of all decide on a tool or an approach. Because a UI whose code consists of anonymous components can only be made testable with great difficulty later on, the “hooks” for automated tests must be implemented from the very beginning.
All visual rules variations require a valid license at runtime. To evaluate out plug-in a request can be made on our web site for a free 30-day license, which is automatically sent via e-mail. All license files contain properties that are verified by the de.innovations.visualrules.license plug-in: This includes a comma-separated list of plug-in names that may be executed by the user, the type of license, the validity period, the name and e-mail address of the licensee and a digital signature preventing manipulation of licensing information.

Purpose

Product
Coding guidelines

Checkstyle (checkstyle.sourceforge.net)
Properties Editor for Unicode

Propedit (sourceforge.jp/projects/propedit/)
Continuous Integration

Cruise Control (cruisecontrol.sourceforge.net)
Installation software

Nullsoft Scriptable Install System (nsis.sourceforge.net)
Documentation

Docbook (docbook.sourceforge.net/)
Table 3: Tool Time – Tools we use for development and release of visual rules

Future outlook
The development of our product is of course continuing. For the coming version we would like to make all visual rules actions and functions accessible to other plug-ins via extension points. In doing so, we will continue to keep an eye focused on segmenting the plug-ins. Future planning also entails implementing specific editors as RCP (Rich Client Platform) applications.

Links & references
[1] Scott Fairbrother, Pat McCarthy, Dan Kehn: The Java Developers Guide to Eclipse, Addison-Wesley, 2004
[2] Eric Clayberg, Dan Rubel: Eclipse Building Commercial Quality Plug-ins, Addison-Wesley, 2004
[3] John Arthorne, Chris Laffra: Official Eclipse 3.0 FAQs, Addison-Wesley, 2004
[4] www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html
[5] www.eclipse.org/eclipse/development/java-api-evolution.html
[7] www.eclipse.org/articles/Article-PDE-Automation/automation.html
[8] www.eclipse.org/articles/Article-UI-Guidelines/Contents.html
[9] www.visual-rules.com

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.