Last revised 16:30 EST November 7, 2003
The objective of the Eclipse Rich Client Platform (RCP) effort is to enable Eclipse to be used in a wide range of end-user applications that are not IDEs.
Our general approach is to factor out the generally useful portions of the existing Eclipse workbench into a generic Eclipse workbench. The generic workbench is still based on views, editors, and perspectives; however, it does not have any of the IDE-specific mechanisms, APIs, or extension points. The generic workbench is configurable so that key UI policy decisions, like whether the workbench window has a tool bar; these are provided by new APIs available to the designer of the application. The Eclipse IDE workbench is built atop the generic Eclipse workbench and uses these new APIs to impose particular policies that give it its distinctive IDE "personality". The generic workbench is located in a plug-in separate from the IDE workbench to allow applications to be built on top of the generic workbench alone, and not require any of the IDE-specific Eclipse plug-ins.
How do we go about finding the minimal set of plug-ins that will be needed in all RCP configurations? The following table lists the plug-ins in the Eclipse Platform (2.1.1 Platform drop for Win32) and their sizes on disk:
Disk size (MB)
|org.eclipse.core.resources (including org.eclipse.core.resources.win32)||0.61|
|org.eclipse.help.ui (including org.eclipse.help.ui.win32)||0.13|
|org.eclipse.platform (including org.eclipse.platform.win32)||0.51|
|org.eclipse.swt (including org.eclipse.swt.win32)||1.23|
|org.eclipse.ui (including org.eclipse.ui.win32)||0.21|
|org.eclipse.update.core (including org.eclipse.update.core.win32)||0.39|
|org.eclipse.update.ui (including org.eclipse.update.ui.win32)||0.76|
It would be relatively straightforward to omit the following Eclipse Platform plug-ins from the minimal RCP configuration:
The rest of the Eclipse Platform plug-ins would need to be included in the minimal RCP configuration:
To maintain binary compatibility, we would add the new application workbench APIs into the existing UI plug-in (org.eclipse.ui and its buddy org.eclipse.ui.workbench have most of the code). We would create a new plug-in for the IDE (org.eclipse.ui.ide). This new plug-in would contain the implementation of the IDE application, although much of the IDE would still be implemented by code within the existing org.eclipse.ui.workbench plug-in, since that it where it is now. The new plug-in would make IDE-specific contributions to the workbench extension points. The new plug-in would not be included in the minimal RCP configuration, ensuring that the generic workbench does not include IDE-specific perspectives, views, actions, etc.
This approach would provide binary compatibility of 3.0 plug-ins over 2.1, while allowing us to introduce new mechanisms so that non-IDE applications could be built on the RCP base. This approach, however, has three shortcomings:
As the Eclipse workbench grows in future releases with new APIs and extension points, it is likely that the API clutter and disk bloat will also increase because it will not always be possible to avoid putting new IDE-specific pieces into plug-ins in the RCP base. So both of these problems will tend to get worse as Eclipse evolves.
These shortcomings are significant enough to warrant considering breaking API binary compatibility in order to address them.
Severing ties to resources (and the IDE-specific dialogs, etc.) would reduce the minimum RCP configuration by about 0.8 MB. Severing the ties to text editors would reduce it by 0.74 MB; to the standard views, by another 0.32 MB. All this would reduce the minimal RCP configuration from 8.04 MB to about 6.1 MB. Of that 6.1 MB, 2.06 MB is the runtime, 0.26 MB is help, and the rest (3.75 MB) is the workbench UI. There are no straightforward ways to reduce the size of the workbench UI further, so 6.1 MB can be considered a lower bound on the size of the minimum RCP configuration (obviously, this bound changes if the size of the Platform runtime changes, which is likely due to 3.0 efforts on other fronts).
Severing ties to text editors is quite simple (most of the hard work was already done in 2.1). The only breaking API changes required to achieve this are:
Porting in light of this kind of breakage is straightforward: it involves changing existing plug-in manifest files; plug-in code does not need to be changed or recompiled.
Severing ties to resource- and IDE-specific things is only a bit more work. The breaking API changes required to achieve this are:
The first 3 kinds of changes are similar to the above: porting involves changing existing plug-in manifest files. The last kind of breakage involves changing code. By design, the Eclipse workbench APIs are generic and independent of particular editors and views, and the underlying data model is largely independent of the workspace. Unfortunately, a small number of unwanted dependencies crept in late in the 1.0 release. There are a handful of API methods that would need to be removed in order to make the workbench API completely generic and free from IDE-specific influences:
We also believe that the changes required to port existing plug-ins will be straightforward. Most of the method changes have to do with opening editors; none of the method are in particularly high-traffic parts of the API. So it is conceivable that some existing plug-ins will require no code changes. Changes to plug-in manifest files are more likely.
This modest amount of breakage is all that would be required to both eliminate the API clutter of IDE-specific elements and reduce the disk footprint of the RCP configuration to the practical minimum. Somewhat perversely, the damage from these changes only befalls existing customers of the Eclipse IDE (there are no Eclipse RCP customers to break yet). To existing IDE customers, the RCP is orthogonal to their direct interests. So they should not be expected to be particularly sympathetic to changes which can be seen as netting them nothing. The benefits of the breakage accrue to the RCP customers; the pain, to existing IDE customers.
It comes down to this question: in the big Eclipse picture, would the long terms gains of making these breaking changes outweigh the short term pain to existing clients?
We think so. We believe that these breaking changes will lead to a significantly cleaner and smaller Eclipse RCP, which will provide the best possible starting point for growing a future base of applications based on the Eclipse RCP, including the Eclipse IDE. We therefore advocate this second approach, rather than the first one which would preserve binary compatibility but would result in a less than ideal starting point for the Eclipse RCP.
For the sake of completeness, here are the alternative approaches to minimizing breakage that we considered but rejected.
We considered splitting API interfaces into a generic interface with a resource-specific subinterface. For example, we considered introducing the interface IGenericWorkbenchPage and changing IWorkbenchPage to be a subclass of it; most of the existing methods would remain on IGenericWorkbenchPage, and IWorkbenchPage would have only the resource-specific openEditor methods. We quickly concluded that this would not be very tasty because of page listeners with methods like IPageListener.pageActivated(IWorkbenchPage) which would now need to accept IGenericWorkbenchPage; adding such a method to the IPageListener interface would break binary compatibility because clients implement this interface. This would force us to instead create of a new interface, IGenericPageListener, and a new set of methods on IGenericWorkbenchPage for adding and removing these listeners. This ripple effect would duplicate a lot of the existing workbench API interfaces and methods, making the API more bloated for everyone. So we abandoned this approach.
We considered leaving the org.eclipse.core.resources plug-in as a part of the minimal configuration, and allowing the generic workbench pre-req it. We could do this and still rid the workbench implementation of the assumption that the workspace is the underlying data model. This would eliminate the API breakage due to removing the resources plug-in as a prereq of org.eclipse.ui. However, this arrangement means that there is still the risk that resource dependencies will creep back in (as they did in the past), and that the code for the org.eclipse.core.resources plug-in (0.61 MB) is still in the base configuration. The footprint matter could be addressed by providing a dummy org.eclipse.core.resources plug-in to be used in configurations where resources are not needed. The code JAR for this plug-in would contain dummy declarations for the minimal set of API interfaces and classes needed to satisfy the class loader when loading API from the org.eclipse.ui plug-in. While this approach would have a minimal footprint, it was rejected because of the general complications and myriad possibilities for confusion surrounding this dummy plug-in (which would need to share the plug-in id and version id with the real plug-in but have different contents), and still runs the risk that resource dependencies will creep back.