While the Eclipse platform is designed to serve as an open tools platform, it is architected so that its components could be used to build just about any client application. The minimal set of plug-ins needed to build a rich client application is collectively known as the "Rich Client Platform."
[This documentation is under construction. The following info has been pulled out of the old SDK roadmap.]
The platform runtime core implements the runtime engine that starts the platform base and dynamically discovers plug-ins. A plug-in is a structured component that describes itself to the system using a manifest (plugin.xml) file. The platform maintains a registry of installed plug-ins and the function they provide.
Function is added to the system using a common extension model. Extension points are well-defined function points in the system that can be extended by plug-ins. When a plug-in contributes an implementation for an extension point, we say that it adds an extension to the platform. Plug-ins can define their own extension points, so that other plug-ins can integrate tightly with them.
The extension mechanisms are the only means of adding function to the platform and other plug-ins. All plug-ins use the same mechanisms. Plug-ins provided with the Eclipse SDK do not use any private mechanisms in their implementation.
Extensions are typically written in Java using the platform APIs. However, some extension points accommodate extensions provided as platform executables, ActiveX components, or developed in scripting languages. In general, only a subset of the full platform function is available to non-Java extensions.
A general goal of the runtime is that the end user should not pay a memory or performance penalty for plug-ins that are installed, but not used. A plug-in can be installed and added to the registry, but the plug-in will not be activated unless a function provided by the plug-in has been requested according to the user's activity.
The best way to get a feel for the runtime system is to build a plug-in. See Plug it in: Hello World meets the workbench to get started building a plug-in. Once you have mastered the basics of plug-in writing and you're ready to define your own extension points, see Defining an extension point.
The workbench UI plug-in implements the workbench UI and defines a number of extension points that allow other plug-ins to contribute menu and toolbar actions, drag and drop operations, dialogs, wizards, and custom views and editors.
Plugging into the workbench introduces the workbench UI extension points and API.
The workbench UI plug-in also provides frameworks that are useful for user interface development. These frameworks were used to develop the workbench itself. Using the frameworks not only eases the development of a plug-in's user interface, but ensures that plug-ins have a common look and feel and a consistent level of workbench integration.
The Standard Widget Toolkit (SWT) is a low-level, operating system independent toolkit that supports platform integration and portable API. It is described in Standard Widget Toolkit.
The JFace UI framework provides higher-level application constructs for supporting dialogs, wizards, actions, user preferences, and widget management. The functionality in JFace is described in Dialogs and wizards, Preferences and properties, and JFace: UI framework for plug-ins.
The Help plug-in implements a platform optimized help web server and document integration facility. It defines extension points that plug-ins can use to contribute help or other plug-in documentation as browsable books. The documentation web server includes special facilities to allow plug-ins to reference files by using logical, plug-in based URLs instead of file system URLs.
Additional features are provided for integrating help topics in product level documentation configurations.
The help facility is described in Plugging in help.