This page describes the migration of NiCE 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. NiCE currently runs fine on a 4.x build using the bridge, but ideally every piece of NiCE would be migrated from the 3.x RCP to the 4.x EAP.
NiCE's Eclipse 4 plug-in is called
gov.ornl.nice.client.e4
and is available in the branches directory of the repository. [TOC]
The public release of NiCE 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.
NiCE 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
gov.ornl.nice.client.eclipse.rcp plugin.xml
file's "product" section:
<property
name="applicationXMI"
value="org.eclipse.platform/LegacyIDE.e4xmi">
</property>
<property
name="cssTheme"
value="org.eclipse.e4.ui.css.theme.e4_default">
</property>
NiCE must also be built on a 4.x target. We recommend the pre-configured 4.2.2 target that can be found in the repository at https://niceproject.svn.sourceforge.net/svnroot/niceproject/trunk/targets/gov.ornl.nice.target.juno.
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 NiCE'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 they 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. NiCE's
ItemViewer
is a good example.
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: