Eclipse

Before we can begin to describe EMF, the Eclipse Modeling Framework, a basic introduction to Eclipse would seem in order. If you're already familiar with Eclipse, you can skip this chapter and go straight to Chapter 2, which is the "real" Chapter 1 from the EMF perspective.

Eclipse is an open source software development project, the purpose of which is to provide a highly integrated tool platform. The work in Eclipse consists of a core project, which includes a generic framework for tool integration, and a Java development environment built using it. Other projects extend the core framework to support specific kinds of tools and development environments. The projects in Eclipse are implemented in Java and run on many operating systems including Windows and Linux.

By involving committed and enthusiastic developers in an environment organized to facilitate the free exchange of technology and ideas, Eclipse is hoping to create the best possible integration platform. The software produced by Eclipse is made available under the Common Public License (CPL), which contains the usual legalese, but basically says that you can use, modify, and redistribute it for free, or include it as part of a proprietary product. The CPL is Open Source Initiative (OSI)-approved and recognized by the Free Software Foundation as a free software license. Any software contributed to Eclipse must also be licensed under the CPL.

Eclipse.org is a consortium of a number of companies that have made a commitment to provide substantial support to the Eclipse project in terms of time, expertise, technology, or knowledge. The projects within Eclipse operate under a clearly defined charter that outlines the roles and responsibilities of the various participants including the board, Eclipse users, developers, and the project management committees.
The Projects
The development work in Eclipse is divided into three main projects: the Eclipse Project, the Tools Project, and the Technology Project. The Eclipse Project contains the core components needed to develop using Eclipse. Its components are essentially fixed, and downloadable as a single unit referred to as the Eclipse SDK (Software Development Kit). The components of the other two projects are used for specific purposes and are generally independent and downloaded individually. New components are added to the Tools and Technology projects on an ongoing basis.

1.1.1 The Eclipse Project
The Eclipse Project supports the development of a platform, or framework, for the implementation of integrated development environments (IDEs). The Eclipse framework is implemented using Java but is used to implement development tools for other languages as well (for example, C++, XML, and so on).

The Eclipse project itself is divided into three subprojects: the Platform, the Java Development Tools (JDT), and the Plug-in Development Environment (PDE). Collectively, the three subprojects provide everything needed to extend the framework and develop tools based on Eclipse.

The Platform is the core component of Eclipse and is often considered to be Eclipse. It defines the frameworks and services required to support the plugging in and integration of tools. These services include, among others, a standard workbench user interface and mechanisms for managing projects, files, and folders. We'll describe the platform in more detail in Section 1.2.

The JDT is a full-function Java development environment built using Eclipse. Its tools are highly integrated and representative of the power of the Eclipse platform. It can be used to develop Java programs for Eclipse or other target platforms. The JDT is even used to develop the Eclipse project itself.

The PDE provides views and editors to facilitate the creation of plug-ins for Eclipse. The PDE builds on and extends the JDT by providing support for the non-Java parts of the plug-in development activity, such as registering plug-in extensions, and so on.

1.1.2 The Tools Project
The Eclipse Tools Project defines and coordinates the integration of different sets or categories of tools based on the Eclipse platform. The C/C++ Development Tools (CDT) subproject, for example, comprises the set of tools that define a C++ IDE. Graphical editors using the Graphical Editing Framework (GEF), and model-based editors using EMF (the subject of this book) represent categories of Eclipse tools for which common support is provided in Tools subprojects.

1.1.3 The Technology Project
The Eclipse Technology Project provides an opportunity for researchers, academics, and educators to become involved in the ongoing evolution of Eclipse. Of particular interest in the context of this book is the XML Schema Infoset Model subproject, which is an EMF-based library for reading and manipulating an XML Schema definition (XSD).
The Eclipse Platform
The Eclipse Platform is a framework for building IDEs. It's been described as "an IDE for anything, and nothing in particular" [1], which is pretty much the way you could think of any framework. It simply defines the basic structure of an IDE. Specific tools extend the framework and are plugged into it to define a particular IDE collectively.

1.2.1 Plug-In Architecture
A basic unit of function, or a component, in Eclipse is called a plug-in. The Eclipse Platform itself and the tools that extend it are both composed of plug-ins. A simple tool may consist of a single plug-in, but more complex tools are typically divided into several.

From a packaging perspective, a plug-in includes everything needed to run the component, such as Java code, images, translated text, and the like. It also includes a manifest file, named plugin.xml, that declares the interconnections to other plug-ins. It declares, among other things, the following:

Requires— its dependencies on other plug-ins.

Exports— the visibility of its public classes to other plug-ins.

Extension Points— declarations of functionality that it makes available to other plug-ins.

Extensions— its use (implementation) of other plug-ins' extension points.

On startup, the Eclipse Platform discovers all the available plug-ins and matches extensions with their corresponding extension points. A plug-in, however, is only activated when its code actually needs to run, avoiding a lengthy startup sequence. When activated, a plug-in is assigned its own class loader, which provides and enforces the visibility declared in the manifest files.

1.2.2 Workspace Resources
Integrated Eclipse tools work with ordinary files and folders, but they use a higher-level API based on resources, projects, and a workspace. A resource is the Eclipse representation of a file or folder that provides the following additional capabilities:

Change listeners can be registered to receive resource change notifications (called resource deltas).

Markers, such as error messages or to-do lists, can be added to a resource.

The previous content, or history, of a resource can be tracked.

A project is a special folder-type resource that maps to a user-specified folder in the underlying file system. The subfolders of the project are the same as in the physical file system, but projects are top-level folders in the user's virtual project container, called the workspace. Projects can also be tagged with a particular personality, called a nature. For example, the Java nature is used to indicate that a project contains the source code for a Java program.

1.2.3 The UI Framework
The Eclipse UI Framework consists of two general-purpose toolkits, SWT and JFace, and a workbench UI that defines the overall structure of an Eclipse IDE.

SWT
SWT (Standard Widget Toolkit) is an OS-independent widget set and graphics library, implemented using native widgets wherever possible. This is unlike Java's AWT, which provides a native implementation only for low-level widgets like lists, text fields, and buttons (that is, the lowest common denominator of all the OSs), and defers to Swing's emulated widgets for the rest. In SWT, emulated widgets are only used where no native implementation is possible, resulting in a portable API with as much native look-and-feel as possible.

JFace
JFace is a higher-level toolkit, implemented using SWT. It provides classes to support common UI programming tasks such as managing image and font registries, dialogs, wizards, progress monitors, and so on. The JFace API does not hide SWT, but rather works with and expands on it.

A particularly valuable part of JFace is its set of standard viewer classes. Viewer classes for lists, trees, and tables work with corresponding SWT widgets, but provide a higher-level connection to the data they're displaying. For example, they include convenient mechanisms for populating themselves from a data model and for keeping themselves in sync with changes to the model.

Another widely used part of JFace is its action framework, which is used to add commands to menus and toolbars. The framework allows you to create an action (to implement a user command), and then contribute the action to a toolbar, menu bar, or context menu. You can even reuse the same action in all three places.

Workbench
The workbench is the main window that the user sees when running Eclipse; it's sometimes referred to as the Eclipse desktop.[1] It is itself implemented using SWT and JFace. As the primary user interface, the workbench is often considered to be the Platform.

[1] Although primarily intended for GUI-based development, the Eclipse platform can also be used to implement non-GUI applications by running a "headless" workbench.

The main workbench window consists of an arrangement of views and editors. A standard Navigator view displays workspace projects, folders, and files. Other views, some standard and others that are tool specific, display information about a resource being edited or possibly the current selection in another view. For example, the standard Properties view is often used to display the properties of an object selected in the Navigator view.

An editor can be launched on a resource from the Navigator view. Eclipse editors work in the usual way, but they are integrated into the workbench window instead of launched externally in their own window. When activated, an editor will contribute its actions to the workbench's menus and toolbar.

The arrangement of views and editors in the workbench window can be customized to suit a particular task. A particular default arrangement is called a perspective in Eclipse. The Debug perspective, for example, decreases the size of the main source window in favor of views displaying variables, breakpoints, and other debugging information.

The primary way to extend the Eclipse platform is using extension points provided by the workbench. These extension points allow tools to add new editors, views, or perspectives to the workbench. Tools can also customize existing editors, views, or perspectives for their own purposes.