Difference between revisions of "Eclipse4/RCP/Compatibility Layer/Migration"

From Eclipsepedia

< Eclipse4‎ | RCP
Jump to: navigation, search
(Undo revision 245841 by Briandealwis.gmail.com (Talk))
Line 7: Line 7:
  
 
It should be noted that the absence of compiler errors does not indicate API-cleanliness. Interfaces marked with <tt>@noimplement</tt> may be being implemented and classes marked with <tt>@noextend</tt> may have been subclassed. Care should be taken to ensure that these API tags are being honoured.
 
It should be noted that the absence of compiler errors does not indicate API-cleanliness. Interfaces marked with <tt>@noimplement</tt> may be being implemented and classes marked with <tt>@noextend</tt> may have been subclassed. Care should be taken to ensure that these API tags are being honoured.
 
== 3.x and 4.x API Comparisons ==
 
 
 
<table border=0>
 
 
<!-- ===================================================================== -->
 
<td colspan=2>
 
<h3>Accessing the status line</h3>
 
</td>
 
<tr>
 
    <td style="background:#ebd3d2;">Eclipse 3.x</td>
 
    <td style="background:#dbf1d2;">Eclipse 4.0</td>
 
</tr>
 
<tr>
 
<td style="background:#ebd3d2;">
 
<pre>
 
getViewSite()
 
  .getActionsBars()
 
      .getStatusLineManager()
 
          .setMessage(msg);
 
</pre>
 
</td>
 
<td style="background:#dbf1d2;">
 
<pre>
 
@Inject
 
IStatusLineManager statusLine;
 
...
 
statusLine.setMessage(msg);
 
</pre>
 
</td>
 
</tr>
 
 
<!-- ===================================================================== -->
 
<td colspan=2>
 
<h3>Associating help context with a control</h3>
 
</td>
 
<tr>
 
<td style="background:#ebd3d2;">
 
<pre>
 
getSite()
 
  .getWorkbenchWindow()
 
    .getWorkbench()
 
      .getHelpSystem().setHelp(
 
              viewer.getControl(), some_id)
 
</pre>
 
</td>
 
<td style="background:#dbf1d2;">
 
<pre>
 
@Inject
 
IWorkbenchHelpSystem helpSystem;
 
...
 
helpSystem.setHelp(
 
        viewer.getControl(), some_id);
 
</pre>
 
</td>
 
</tr>
 
 
<!-- ===================================================================== -->
 
<td colspan=2>
 
<h3>Handling errors and exceptions</h3>
 
</td>
 
 
<tr>
 
<td style="background:#ebd3d2;">
 
<pre>
 
try {
 
    ...
 
} catch (Exception ex) {
 
    IStatus status = new Status(
 
      IStatus.ERROR, "plugin-id",
 
      "Error while ...", ex);
 
    StatusManager.getManager()
 
        .handle(status, StatusManager.SHOW);
 
}
 
</pre>
 
</td>
 
<td style="background:#dbf1d2;">
 
<pre>
 
@Inject
 
StatusReporter statusReporter;
 
...
 
try{
 
    ...
 
} catch (Exception ex) {
 
    statusReporter.show("Error while ...", ex);
 
}
 
</pre>
 
</td>
 
</tr>
 
 
<!-- ===================================================================== -->
 
<td colspan=2>
 
<h3>Accessing preference values</h3>
 
</td>
 
 
<tr>
 
<td style="background:#ebd3d2;">
 
<pre>
 
IPreferenceStore store =
 
    IDEWorkbenchPlugin.getDefault()
 
        .getPreferenceStore();
 
boolean saveBeforeBuild = store
 
    .getBoolean(SAVE_BEFORE_BUILD);
 
</pre>
 
</td>
 
<td style="background:#dbf1d2;">
 
<pre>
 
@Inject @Preference(SAVE_BEFORE_BUILD)
 
boolean saveBeforeBuild;
 
</pre>
 
</td>
 
</tr>
 
 
</table>
 

Revision as of 15:13, 7 April 2011

In order to ensure a smooth migration of 3.x plug-ins running on top of a 4.x base, there are several things that need to be checked to prevent headaches further down the road.

APIs and Internals

As detailed on the limitations of the Compatibility Layer, the org.eclipse.ui.presentations API has been removed and the org.eclipse.ui.themes extension point is being ignored for some select cases. These references should be searched for to ensure that they have been refactored out into a separate bundle to prevent problems when using the original plug-in on a 4.x base.

The org.eclipse.ui.actionSets extension point has been deprecated in the 4.x stream. While they may still be used on 3.x, it is recommended to migrate code that uses the actionSets and objectContributions extension points to the Eclipse 3.3 org.eclipse.ui.menus extension point.

It should be noted that the absence of compiler errors does not indicate API-cleanliness. Interfaces marked with @noimplement may be being implemented and classes marked with @noextend may have been subclassed. Care should be taken to ensure that these API tags are being honoured.