Skip to main content

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.

Jump to: navigation, search

Eclipse4/API

The Eclipse 4 platform is currently defining its API for the Eclipse 4.3 release.

API Pages

Application model - Discussion on model elements to be released as API

Annotations - Discussion on annotations to be released as API

Other information

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 e4 API can be broken into a number of distinct areas:

  • UI Model - This is the EMF model we use to define the User Interface along with any defined constants used as tags or as keys for either persistant or transient data. It also includes the API used to render the UI Model.
  • DI / IEclipseContext - This includes the DI api itself as well as any Eclipse 4 relevant annotations
  • Application Context  - This includes anything that we guarantee will be available in a particular context; Services, MApplication, Selection...
  • CSS - This includes 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...)

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)

Copyright © Eclipse Foundation, Inc. All Rights Reserved.