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"
(Undo revision 245841 by Briandealwis.gmail.com (Talk)) |
Bsd.acm.org (Talk | contribs) (→Poor Man's Injection) |
||
| (One intermediate revision by one other user not shown) | |||
| 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. | ||
| + | |||
| + | |||
| + | == 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 <tt>IServiceLocator</tt> are performed using the <tt>IEclipseContext</tt>. So view parts and editor parts can resolve items through the context using <tt>IWorkbenchSite#getService(XXX)</tt>. For example, to obtain the <tt>IEclipseContext</tt>, you might do the following: | ||
| + | <source lang="java"> | ||
| + | public class MyPart extends ViewPart { | ||
| + | // ... | ||
| + | void doIt() { | ||
| + | IEclipseContext context = (IEclipseContext) getSite().getService(IEclipseContext.class); | ||
| + | } | ||
| + | // ... | ||
| + | } | ||
| + | </source> | ||
| + | |||
| + | ==== Performing Injection ==== | ||
| + | You can also make and inject your own classes using the <tt>ContextInjectionFactory</tt>: | ||
| + | <source lang="java"> | ||
| + | IEclipseContext context = ...; | ||
| + | Foo createdObject = ContextInjectionFactory.make(Foo.class, context); | ||
| + | </source> | ||
| + | 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. | ||
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.