12-12-2012, 11:00 AM
Eclipse Platform Technical Overview
eclipse-overview.pdf (Size: 361.08 KB / Downloads: 18)
Abstract:
The Eclipse Platform is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as web sites, embedded JavaTM programs, C++ programs, and Enterprise JavaBeansTM. This paper is a general technical introduction to the Eclipse Platform. Part I presents a technical overview of its architecture. Part II is a case study of how the Eclipse Platform was used to build a full-featured Java development environment.
Introduction
The Eclipse Platform is an IDE for anything, and for nothing in particular.
Figure 1 shows a screen capture of the main workbench window as it looks with only the standard generic components that are part of the Eclipse Platform.The navigator view (Figure 1, top left) shows the files in the user's workspace; the text editor (top right) shows the content of a file; the tasks view (bottom right) shows a list of to-dos; the outline view (bottom left) shows a content outline of the file being edited (not available for plain text files).
Although the Eclipse Platform has a lot of built-in functionality, most of that functionality is very generic. It takes additional tools to extend the Platform to work with new content types, to do new things with existing content types, and to focus the generic functionality on something specific.
The Eclipse Platform is built on a mechanism for discovering, integrating, and running modules called plug-ins. A tool provider writes a tool as a separate plug-in that operates on files in the workspace and surfaces its tool-specific UI in the workbench. When the Platform is launched, the user is presented with an integrated development environment (IDE) composed of the set of available plug-ins.
The quality of the user experience depends significantly on how well the tools integrate with the Platform and how well the various tools work with each other.
Platform Runtime and Plug-in Architecture
A plug-in is the smallest unit of Eclipse Platform function that can be developed and delivered separately. Usually a small tool is written as a single plug-in, whereas a complex tool has its functionality split across several plug-ins. Except for a small kernel known as the Platform Runtime, all of the Eclipse Platform's functionality is located in plug-ins.
Plug-ins are coded in Java. A typical plug-in consists of Java code in a JAR library, some read-only files, and other resources such as images, web templates, message catalogs, native code libraries, etc. Some plug-ins do not contain code at all. One such example is a plug-in that contributes online help in the form of HTML pages. A single plug-in's code libraries and read-only content are located together in a directory in the file system, or at a base URL on a server. There is also a mechanism that permits a plug-in to be synthesized from several separate fragments, each in their own directory or URL. This is the mechanism used to deliver separate language packs for an internationalized plug-in.
Each plug-in has a manifest file declaring its interconnections to other plug-ins. The interconnection model is simple: a plug-in declares any number of named extension points, and any number of extensions to one or more extension points in other plug-ins.
A plug-in’s extension points can be extended by other plug-ins. For example, the workbench plug-in declares an extension point for user preferences. Any plug-in can contribute its own user preferences by defining extensions to this extension point.
Workspaces
The various tools plugged in to the Eclipse Platform operate on regular files in the user's workspace. The workspace consists of one or more top-level projects, where each project maps to a corresponding user-specified directory in the file system. The different projects in a workspace may map to different file system directories or drives, although, by default, all projects map to sibling subdirectories of a single workspace directory.
A project nature mechanism allows a tool to tag a project in order to give it a particular personality, or nature. For example, the web site nature tags a project that contains the static content for a web site, and the Java nature tags a project that contains the source code for a Java program. The project nature mechanism is open. Plug-ins may declare new project natures and provide code for configuring projects with that nature. A single project may have as many natures as required. This affords a way for tools to share a project without having to know about each other.
Each project contains files that are created and manipulated by the user. All files in the workspace are directly accessible to the standard programs and tools of the underlying operating system. Tools integrated with the Platform are provided with API for dealing with workspace resources (the collective term for projects, files, and folders). Workspace resources are represented by adaptable objects so that other parties can extend their behavior.
Workbench
Unlike SWT and JFace, which are both general purpose UI toolkits, the workbench provides the UI personality of the Eclipse Platform, and supplies the structures in which tools interact with the user. Because of this central and defining role, the workbench is synonymous with the Eclipse Platform UI as a whole and with the main window the user sees when the Platform is running (see Figure 1). The workbench API is dependent on the SWT API, and to a lesser extent on the JFace API. The workbench implementation is built using both SWT and JFace; Java AWT and Swing are not used.
The Eclipse Platform UI paradigm is based on editors, views, and perspectives. From the user's standpoint, a workbench window consists visually of views and editors. Perspectives manifest themselves in the selection and arrangements of editors and views visible on the screen.
Editors allow the user to open, edit, and save objects. They follow an open-save-close lifecycle much like file system based tools, but are more tightly integrated into the workbench. When active, an editor can contribute actions to the workbench menus and tool bar. The Platform provides a standard editor for text resources; more specific editors are supplied by other plug-ins.
Views provide information about some object that the user is working with in the workbench. A view may assist an editor by providing information about the document being edited. For example, the standard content outline view shows a structured outline for the content of the active editor if one is available. A view may augment other views by providing information about the currently selected object. For example, the standard properties view presents the properties of the object selected in another view. Views have a simpler lifecycle than editors: modifications made in a view (such as changing a property value) are generally saved immediately, and the changes are reflected immediately in other related parts of the UI. The Platform provides several standard views (see Figure 1); additional views are supplied by other plug-ins.