Eclipse4/SR1Plan

Eclipse 4.2 SR1 Plan

The goal is to plan out what we can do for SR1. We should be trying to limit the amount of work that we commit to here because there's only a short time in which to work and we have to take into account that it's summer and many of us will be taking vacation and / or will only be working 4 days / week for July.

Bug fixes

We should go over the current list of defects and make sure that we're only attempting to address significant defects. Also we should expect that we will be receiving some good ones from the community that we'll have to address The work for making sure that BiDi and accessibility are OK go into this bucket but are non-negotiable in the sense that this work has already been committed to.

Formal API specifications

This breaks down into 4 basic areas; UI Model, CSS, DI and Services as well as two main activities that have to be done for each area; documentation and refactoring.

The first pass should be to define the scope of the API so that we spend our time documenting and refactoring only those things that we are sure should be API (note that we can likely defer things that are on the fence as 'provisional', giving us the 4.3 cycle to finalize their status).

Refactoring

At this point we can likely refactor within the Eclipse 4 IDE fairly safely since few (if any) of the EPP components are using the current e4 mechanisms. However there will be significant impact on existing e4 code, including tutorials, existing e4 projects, Lars' book (sorry dude!) and even possible existing products. We will have to work closely with the e4 community to make sure that they're ready to move up to the new API as it becomes finalized.

The refactoring exercise includes both normalizing our API definitions:

Should we use "I" for interfaces ? I think that having 'M' for the model is OK but should we change our 'E'nterfaces to regular Interfaces ?

It also means determining the correct package locations and relationships to provide the desired granularity as far as end-user consumption are concerned.

UI Model Documentation

The EMF model should be updated with the basic documentation of types and fields...we'll likely also want to re-package the generated documentation to wherever we put the general documentation.

We also need to provide some general documentation on why the model is structured as it is and on how to manipulate it to get various useful results.

Pictures would be nice :-)

The we need documentation of the relationship between the model, the rendering engine and its associated renderers. This should also explain the various rendering specific tags as well as some of the utilities (CSSRenderingUtils...).

Things to look into:

- We should make the 'visible' attribute provisional in anticipation of changing its name to something less confusing in 4.3.

- We should examine the Commands side of the model to see if it can be simplified. Note that for 4.2.1 this simply means marking the classes that we think we can get rid of as 'provisional' (or 'deprecated' if we're confidant that it'll go away).

Services Documentation

What services constitute our API ? I'd lean more towards only marking those services we are sure of as final while making other candidates provisional.

We might start by looking at what we put into the default E4Application's context to produce a list of candidates...

• EModelService
• EPartService
• EPlaceholderResolver
• IServiceConstants.ACTIVE_PART
• IServiceConstants.ACTIVE_SHELL
• IStylingEngine
• Where are things like the selection service defined ?
• Presumably others such as Logger and EventAdmin are supplied as OSGI services, is it our job to document these?

Again, many of these appear as classes rather than interfaces (Logger...).

Should we be hiding our dependency on OSGI's eventing mechanism behind our own facade ? We could do this by simply providing 'subscribe' / 'unsubscribe' methods as part of the ModelService.

In the SDK we also need a formal way for a client to determine whether they're running on top of 3.x or 4.x and to gain access to the 4.x API.