The Eclipse 4 platform is currently defining its API for the Eclipse 4.3 release.
Application model - The EMF model that defines the User Interface along with any defined constants used as tags or as keys for either persistent or transient data. Also the API used to render the UI Model.
Dependency Injection and Annotations - The dependency injection API and Eclipse 4 relevant annotations
Application Context - Defines what is guaranteed to be available in a particular context; Services, MApplication, Selection...
CSS - The CSS attributes as well as the API needed to support adding CSS support to arbitrary elements (such as the framing support for trim elements...)
About this page
This will eventually be the definitive source for information / documentation on the various different Eclipse 4 APIs. The API will include those parts of the existing e4 API that we decide to graduate out of the incubator as well as the changes in the IDE's API which are needed in order to allow the use of e4-native implementations into Eclipse 4.
Since this is our first attempt to formalize the API we should likely declare only those parts that we are sure are in fact needed and where we don't anticipate needing to make future revisions. Once we formally declare API it then becomes our problem to guarantee that future releases support it so if we're not sure then it's likely best to mark it provisional for now.
The changes necessary to support e4-natives directly in the IDE is as yet TBD but will (at least initially) involve modifying the definition and management of some subset of the current extension points, likely candidates are:
- org.eclipse.ui.views - Need to relax the restriction that all views are subclasses of ViewPart and make sure that we create these views using DI rather that 'wrapping' them in the LegacyPart...
- org.eclipse.ui.perspectives - See what changes we can make to allow an IPerspectiveFactory to skip teh current API and create the UI model for the perspective using e4 api (perhaps using snippets?)
- org.eclipse.ui.handlers - relax the restriction that handlers implement IHandler and make sure that the IDE code recognizes e4 elements and creates them through DI.
As we proceed we can see what we can do to augment the PDE mechanism (i.e. now it knows enough to create a class that's a subclass of 'ViewPart' but the e4 alternative would be to generate a POJO with an @PostConstruct 'createPart' and @Focus methods)