This page is to collect input on how best to provide the backwards compatibility layer, what it needs to cover and hopefully identify some people who are willing to help work on the layer itself. See E4/Compatibility/Running the compatibility layer
At the end of the day in order to be accepted as 'Eclipse' we must have a backwards compatibility story. We've committed to running a majority of existing 'API-clean' plug-ins. There are literally thousands of existing Eclipse components, all written against the current 3.x framework Extensions/API.
One of the main goals is to ensure that we don't dilute the pure E4 mechanisms in the effort to provide backwards compatibility. This means that the compatibility layer itself must be an optional component of an E4 install.
- Bundle Loading - In many cases bundles will have compatibility requirements that must be satisfied before the bundle can even be loaded. For example, the current jdt.ui bundle initially failed to load because it was registering some colors on startup that were expected to be in the PreferenceStore and weren't. This immediately precluded any use of its parts since createExecutableExtension needs to load the bundle first.
- Scoping issues - Part of the compatibility story will require that we provide code-compatible replacements for existing implementation classes (i.e. PlatformUI, ViewPart) while retaining existing implementations where possible. This will likely require some refactoring of the existing 3.x bundle/package structure to allow for a specific bundle containing all classes for which a separate E4 implementation is desired.
- Listeners - One of the most complex parts of the existing code is the vast number of ways that clients can register to listen for changes in the environment. To further complicate matters the listener firing order counts so we'll have to maintain this order at least to some degree. This isn't just a maintenance of the order of the listeners in a particular list but in the order of firing of event from the different lists.
NOTE: Event ordering issues produce some of the most 'interesting' defects we get.
A significant portion of the compatibility layer will have to be in place in order to move the 'self hosting' story beyond the most naive implementation. If we can identify which elements (Views/Editors/Commands) of Eclipse we need to properly self host we can then target the compatibility work towards making these available in an E4 Workbench.
Note that the 'self-hosting' environment outlined below is a fairly high target but let's be realistic. While we can write everything in a text editor we'd be so unproductive that we'd all sneak back to our beloved eclipse to do any real work (defeating the purpose of eating your own dog food).
What do we mean by 'self-hosting'?
This means that we'd be using E4's workbech to develop itself on a day-to-day basis. Over time it would become less and less necessary to resort to 'outside' tooling (legacy eclipse) to get our work done until we are simply using it as we currently do eclipse.
What do we need to self-host?
We're developers so we all know the drill...;-)
- check out what you want to work on
- write some code
- debug the code
- check it in
Pushing along the path towards self-hosting may prove to be an effective means to focus the compatibility efforts; simply taking something like the CVS Repositories view and providing whatever compatibility support it needs in order to come up will teach us a lot and move us along the path a fair ways. Then 'rinse and repeat' for the other components (JDT views...).
OK, we could likely live for a while using legacy eclipse to manage the CVS stuff and work directly against some 'local' projects (oh, that means that some concept of 'project' is needed, along with the builders...) even if we aren't using CVS.
On the other hand losing the JDT support would really cut back on productivity (it's a truly great Java development environment). So perhaps we should focus on getting the JDT editor up. This is admittedly a large (huge?) bite to take first but may well be worth it. By the time it's running chances are that most of the other views...would be fairly simple.
The good news is that by the time we can host these parts we're probably most of the way towards supporting a large segment of all existing parts...
Note that we don't have to have everything working perfectly in order to self-host. For example menu items could all be enabled as long as the needed ones (i.e. Save) actually work.
Providing backwards compatibility for the existing extension points means that the defined extension to the workbench appears and works in a manner appropriate to the intent of the extension.
Some extensions are 'data only' (i.e. they define no 'executable'); they simply inject information into the workbench which is then used in some portion of the UI. The perspective's various 'shortcut' lists all fall into this category, they simply provide info that is used by the New/Import/Export wizards and the 'Show View' menu to populate the appropriate list. These should be relatively simple (they don't require bundle loading for example).
Other extension points are used simply to 'seed' some structure which is then managed by the Workbench itself. An example of this are the 'shortcut' elements of the perpsectives/perspectiveExtensions. You can define a new shortcut in the extension but the IDE also supplies UI to manipulate the values (which are then persisted as part of the workspace).
Some extensions may require either replacement or 'tooling' in order to be integrated into the E4 workbench UI since they are in conflict with some part of E4's architecture. For example the current 'themes' extension point overlaps with E4's CSS story in a way that may require some integration work to make an appropriate CSS style sheet from the legacy theme.
Finally come those extensions that provide the 'meat' of the current UI; Views, Editors and their related Commands structures. These all have at their core an 'executable extension' that implements a defined interface or extends a defined base class. In each case E4 will have to delegate to the compatibility layer to interact with the implementation classes in the correct manner (for example calling the (legacy) ViewPart's 'setFocus' method when the view activates).
Extension Point Dynamics
A goal of the current 3.x stream (and a necessity for e4) is the ability to do 'hot oil change'; this is the ability to perform modifications to the bundle structure without having to perform a restart. For each extension point the affects of new ones coming in or existing ones going away has to be specified.
One issue that's already been identified is that of allowing the bundle management to be performed off of the UI thread. The asynchronous approach (while desirable from a strictly UI perspective) could greatly complicate the internal structure. Take, for example, the 'Show View' dialog; since it would use its EP's information directly (i.e. read it when the dialog opens) it would itself have to react to changes that might occur once it's up based on bundle changes taking place in another thread.
In addition to the extension points Eclipse also defines a number of programmatic API sets; some for use within the regular Eclipse IDE and others specifically for use with RCP apps.
First and foremost amongst these is 'PlatformUI', a singleton that provides access to APIs (generally through an interface) to various aspects of the workbench (its active WorkbenchWindow/Page/Perspective...). Having a replacement for this is crucial since almost any non-naive Eclipse component is going to use PlatformUI in one way or another. Note that the replacement implementation will, by necessity, have to also provide E4-specific implementations of the interfaces that can be accessed through it.