Planning page for Luna

Draft to develop a plan for our work in Luna

Themes

The general themes that we should focus on in Luna.

Exposing Eclipse4 in the Workbench

Hosting Eclipse4 Models

The Workbench (a.k.a compatibility layer) manipulates the model to host 3.x views and editors on it. In Luna we'd like to see Eclipse4 parts and other contributions contributed to the Workbench and provide 3.x wrappers to correctly interact with them in the Workbench.

Menus, Commands, and Handlers

Handlers in the Workbench are currently clustered on their own IEclipseContext just off of the application context. The handlers in Eclipse4 can be instantiated at any MContext level, and that controls their activation and enablement much finer grained. The goal is to expose this distribution on handlers contributed through the Workbench.

IEclipseContext Use

The IEclipseContext represent a runtime hierarchy of information. The goal is to have a regular pattern and predictable use, so that looking up information at any point in the hierarchy will return the appropriate answer.

Some mechanisms it supports we need to rationalize:

1) setting the value for a variable, and then use context.getActiveLeaf().get(variable)

2) using context.modify(variable, value) and then using context.get(variable)

3) setting a variable in the application context that points to a ContextFunction. context.get(variable) will apply the ContextFunction to the current hierarchy.

Fragments and Extension Points

The fragment processing needs some more design work. The goal is to simplify the creation of fragments and to apply them in a standard way that is predictable.

Eclipse Application Services

Logging and Tracing

We need to decide on our logging and tracing strategies, and which APIs to use (ex, just use Equinox Logging and DebugTrace?). Then we need to apply that strategy to many of our new Eclipse4 plugins.

Scheduling Work

There was some discussion about using equinox concurrent support, and re-framing our scheduling/progress in terms of that. We need to analyze the difference between Jobs and IWorkbenchRunnableWithProgress and the concurrent support, and then look at our Eclipse4 level support. i.e. Do we use Jobs + provide Progress? Does Jobs need to be in terms of equinox concurrent? Do we need a parallel progress pattern with equinox concurrent?

Save Lifecycle

We need to provide the fully functioning Eclipse4 save lifecycle, that the Workbench save lifecycle can be implemented on top of.

Workbench Services Decoupling

It's always been our goal to break up many of the Workbench services so they can be consumed by Eclipse4 applications without consuming the entire Workbench. Some examples:

Application Startup and Lifecycle

The goal is that the Eclipse4 application startup and lifecycle make sense, and the Workbench startup fits in the appropriate place.

For example, it's reasonable that the Workbench startup should create a useful model that can then be passed to the Eclipse4 application startup. There are a number of lifecycle hooks that should probably be made available in the Eclipse4 startup.