Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Eclipse4/RCP/Compatibility Layer/Migration"
Bsd.acm.org (Talk | contribs) |
Bsd.acm.org (Talk | contribs) (→Poor Man's Injection) |
||
| Line 22: | Line 22: | ||
<source lang="java"> | <source lang="java"> | ||
public class MyPart extends ViewPart { | public class MyPart extends ViewPart { | ||
| + | // ... | ||
void doIt() { | void doIt() { | ||
IEclipseContext context = (IEclipseContext) getSite().getService(IEclipseContext.class); | IEclipseContext context = (IEclipseContext) getSite().getService(IEclipseContext.class); | ||
} | } | ||
| + | // ... | ||
| + | } | ||
</source> | </source> | ||
Latest revision as of 17:39, 27 June 2012
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.
Contents
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.
Using Eclipse 4 Features
The Eclipse 3.x Compatibility Layer is an Eclipse 4 application on its own right, however it makes many assumptions in how it uses the Eclipse 4 application model. Eclipse 4.2 does not officially support hybridization of Eclipse 3.x apps interacting with the underlying Eclipse 4 model.
Dependency Injection
IWorkbenchParts are not injected, and it can be a bit of a pain to expose injection to apps based on the E3.x APIs.
Poor Man's Injection
In Eclipse 4, the implementors of IServiceLocator are performed using the IEclipseContext. So view parts and editor parts can resolve items through the context using IWorkbenchSite#getService(XXX). For example, to obtain the IEclipseContext, you might do the following:
public class MyPart extends ViewPart { // ... void doIt() { IEclipseContext context = (IEclipseContext) getSite().getService(IEclipseContext.class); } // ... }
Performing Injection
You can also make and inject your own classes using the ContextInjectionFactory:
IEclipseContext context = ...; Foo createdObject = ContextInjectionFactory.make(Foo.class, context);
Foo's lifecycle is now tied to the context: when the context is disposed (i.e., because the view has been disposed), the Foo instance will be destroyed too.