Moving a RCP application from Galileo to Helios: feedback and tips

aurelien.pupier's picture
aurelien.pupier
Tuesday, July 20, 2010 - 18:13
Blog Categories: 
Eclipse

In this post I'm going to share our experience migrating our RCP product Bonita Open Solution from an Eclipse 3.5.1 to 3.6.0 based platform. There were some issues but we were successful. I will also offer some tips so you can avoid some mistakes and save migration time.

Dynamic Services

This one was the trickiest to identify and fix because the only way to find it is in a stacktrace with NPE in the log. In fact, FrameWorkAdminService is launched via Declarative Services in 3.6 and so you need to add org.eclipse.equinox.ds in your plugin-based product definition. And be careful, this plugin is not identified as required. This is the "drawback of using Dynamic Services" (to quote Lars Vogel). This same issue is also problematic with e4. You can find the related bug here.

GMF

The issues

  • In order to identify potential issues we tested the migration with RC1 and RC2. There were some API modifications that were out of phase between GMF and qvtOML with the RC1 and RC2 releases. It took some time to find them and we needed the qvtOML milestones update site to make it work.
  • On one of our high custom editors, we could no longer reparent (move a figure inside another). Canonical Edit Policies has been improved in order to fix this annoying bug. For that reason, a new method has appeared in GMF templates to override the refreshSemantic method. So, first, I removed the overridden method -- but the copy/paste didn't work after that. The trick is to keep the overridden method and add to the end of this method, not at the beginning, a call to the super method. You can take a look at this bug and see our aspect template for more information.

The advantage

Using providers and Aspect templates limits the amount of customized code to check. In fact most of the modifications were done to remove some fixes as they are now in the new release (canonical diagram empty after restart, save as saving only diagram and others). So moving to Helios simplifies Bonita Open Solution code.

Tests

There is very good news here: Eclipse is now using JUnit 4 by default! Now you can write your plugin tests with JUnit4, and this avoids a lot of struggle trying to get both standard plugins tests and JUnit4/SWTBot tests working together. Both kinds of test can now run without any hack, using the provided JUnit, and the org.eclipse.ant.optional.junit fragment loaded in your product.

Target platform

  • Kudos to greclipse which provides a zipped update site to test on Helios. However upgrading the target platform for greclipse 2.0.2 for Eclipse 3.6 was a little complicated due to a patched org.eclipse.jdt.core (can't uninstall on the target platform/conflict with patched jdt.core).
  • It seems that BIRT doesn't provide an update site to test 2.6 on RC releases. So we kept the 2.5.1 version of BIRT. The good news is that the 2.5.1 version works great with Eclipse 3.6.
  • A little tip: use p2 to construct your target platform and keep all feature names with their repositories. They will be helpful for your next migration.

In a nutshell, there are difficulties migrating to Eclipse 3.6 but it is definitely do-able!

I wish you a good migration, hoping that my feedback will help you, and look forward to your tips and feedback from your successful migration.

Notifications