Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search

Migrating ICE to Eclipse 4

This page describes the migration of ICE from an Eclipse 3.7.2 (Indigo) RCP application to an Eclipse 4.2.2 (Juno) application. The migration is a long running effort and will not be complete until Eclipse 4.x natively supports Eclipse Forms without the 3.x to 4.x bridge. ICE currently runs fine on a 4.x build using the bridge, but ideally, every piece of ICE would be migrated from the 3.x RCP to the 4.x EAP.

ICE's Eclipse 4 plug-in is called and is available in the branches directory of the repository.

Time table for full adoption

The public release of ICE will be built on Eclipse 4 using the bridge sometime in late April after under going thorough tests to compare it to the Indigo-based version.

There are no plans to migrate to a native Eclipse 4 port until Forms are supported.

Changes for the 3.x to 4.x bridge

ICE does not require any source code changes to work with the Eclipse 3.x to 4.x bridge. However, the following lines must be added to the product section of the plugin.xml file's "product" section:


ICE must also be built on a 4.x target. We recommend the pre-configured 4.2.2 target that can be found in the ICE Repository

Changes for native 4.x pieces

There is no distinction between Editors and Views in Eclipse 4. Instead, both are combined in the concept of Parts. (Recall that in Eclipse 3.x a Part was the base class for Editors and Views.) New parts, but not the SWT code that draw the contents of those parts, have been created for ICE's e4 port.

PartSashContainers and PartStacks were created to replace the layout configured in the plugin.xml file from the 3.7.2 version. A horizontally split PartSashContainer was used as the base with the left containing a vertically split PartSashContainer with PartStacks to reproduce the vertical stacking of the ItemViewer and TransformationViewer. The same scheme was used on the right side of the base container to reproduce the vertical stacking of the FormEditor space and the Console View, except the FormEditor space is an Area, not a PartStack.

Handlers and Commands were added as needed to replace the 3.7.2 Commands, but in most cases the new Commands just called modified versions of the old ones.

Views are now implemented as standalone SWT classes that have their parents injected with the @Inject clause.

A very important point that is not mentioned in the more common tutorials is that, at least as far as we can tell, @Inject should be used to inject the parent composite on a constructor or init() operation and @PostConstruct should be called after that step to set input or connect to a remote resource. ICE's ItemViewer is a good example.

Tricky e4 Things

When injecting resources with URIs, it is bundleclass:// and platform:/ with the first having two forward slashes and the second having only one forward slash after the semicolon. It is important to note that fixing the width or height of a PartStack is done by the putting a number in the obscurely named Container Data field in the editor and that the weighting is done in thousandths. So, to weight two Parts that are vertically stacked in a PartSashContainer with a 75/25 split, one Part must have Container Data set to 75000 and the other should have it set to 25000 instead of .75 and .25 or 75 and 25.

@Execute is only meant to be used in Handles.

@Inject and @PostConstruct should be used in Parts.


The following references were used for this work:

Back to the top