Unit Testing RCP Applications

Include Unit tests launching and stop in case of failure in a continuous integration process is a MUST. In the case of an Eclipse RCP application continuous environment process (based on ANT and PDE build scripts) set up we have to decide “how to install and launch unit tests“.

Solution: After building the RCP product, install the product using P2 director command line in the Eclipse SDK that has been used to build the product with a specific configuration. Then just launch the PDE unit test application as following:

 <java dir="./plugins" classname="org.eclipse.equinox.launcher.Main" fork="yes" classpathref="equinox.launcher.class.path" maxmemory="512m">
 <arg line="-application org.eclipse.pde.junit.runtime.uitestapplication -port ${port} -testpluginname ${plugin} -classnames ${classes} ${config}" />

This solution is great but has a main drawback: We are not running the unit tests in the “final” environment but in an SDK environment that has been enhanced with our RCP product.  A better solution to my eye will be to enhance the RCP product with the few plugins required by PDE unit test application in order to be closest to the final environment when launching the tests.

I’am investigating on that ….. next episode coming soon !

Note: feel free to comment this post to bring your point of view and experiences about RCP unit testing.


How Deliver RCP Patches and Updates ??

I have been working on an RCP application delivered to internal customers inside my (big) company during the last months. I already have a satisfying headless build for this application, generating a full package as a zip archive that is already delivered to the previously mentioned internal customers as release 0.9.6 (several releases have been done).

We plan now to deliver the 1st (1.0.0) “official” release for the beginning of the 2011. In this context we are thinking about the best strategy to handle updates and patches that will be done on top of this 1.0.0 release. To better understand the context here is the RCP product’s content:

  1. org.eclipse.rcp feature provided by the Eclipse Foundation
  2. my.company.generic feature provided by an other team in my company and delivered as P2 repository.
  3. my.company.product feature wrote by myself.

Our requirements regarding the updates/patches installation are the following ones:

  1. User must update the RCP application as a global action and doesn’t care which feature among the 3 features of the product is updated/patched
  2. Some users have access to our (through internal network) P2 update/patches repository and others don’t
  3. It’s not yet possible to add new optional “software” (features in Eclipse’s terminology) to the product

To handle the 1st requirement I decided to adopt the same policy to update OR to patch the product with increment of the product version. Each time the product feature (2) OR the product required feature (3) I’ll will upgrade the product version number, the product feature (2) number if this is the modified feature and I’ll perform a full rebuild of the product and update the p2 repository with the result of this build.

Regarding requirements number 2, I maintain an up to date p2 repository for users having access to it and provide a zipped version of the same repository each time it is updated for other. This solution will work but will enforce users without access to the repository to get a full zipped archive each time the product is updated even if for example only the required feature (2) is modified. Can you see a better solution to handle this situation ?

For the last requirement, I decided to not use the P2 UI and write my own update UI code as mentioned in this Eclipse wiki. It seems not so easy but feasible.

Feel free to tell us about your RCP’s experience regarding updating and patching by commenting this post,


Simple Configurator AND Update Configurator

In the context of an RCP application and following this previous post, I am building my app using Features including the org.eclipse.rcp one. I recently decided to add the error log view to my product in order to inform users of what was wrong and to respect the following recommendation: “Don’t ignore that Error !!!“.

To do that I just added the error log view in my perspective and added a dependency on the org.eclipse.ui.views.log plugin in one of my plugin to have it included at build time. All is working fine but ….

When I first launch a freshly installed application I get several errors (but the tool behaves properly according to my test suites) such as:

“Could not install bundle plugins/org.eclipse.ui_3.5.2.M20100120-0800.jar   Bundle “org.eclipse.ui” version “3.5.2.M20100120-0800″ has already been installed from: reference:file:plugins/org.eclipse.ui_3.5.2.M20100120-0800.jar”

After long investigations and deep debugging of Eclipse, I concluded that both  org.eclipse.update.configurator and org.eclipse.equinox.simpleconfigurator where installed in my product. As a consequence they are both trying to install plugins, and for some plugins (I don’t know exactly when yet) they install the same plugins. Removing manually the Update Configurator plugin (it seems to be the old way to install bundles in Eclipse) from my product solves the issue. Unfortunately this plugin is included with the simple configurator plugin in the RCP feature on which I depend.

So for now I removed the dependency on RCP feature and “manually” manage the plugins required by my product. I am not satisfy on this solution and would be interested to get community thoughs on this topic. Any pointers on the subject are welcome.