The motivation then for other open source licenses is to encourage and support commercial use and distribution of open source software by allowing developers to maintain their own contributions as proprietary. Among the licenses that do this is the Eclipse Public License (EPL). Specifically, the EPL allows a developer to license his own contributions under the license of his choice provided its provisions don’t conflict with the EPL.
This works well for software like Eclipse that is based on a “plug-in” concept to extend the base platform. Plug-ins are independent software modules that communicate with the platform through well-defined interfaces. So while the platform itself is open source, plug-ins may be proprietary.
1.3 Status of Eclipse
In addition to the Eclipse platform itself, Eclipse comprises dozens of tool-oriented and application-oriented projects that operate as independent open source projects. For the past three years, usually in June, the foundation has organized a coordinated major release of the platform along with a large number of the constituent sub-projects. This allows users to try out new features without worrying about version incompatibility among the various tools.
Interestingly, these releases are named after the moons of Jupiter. The 2008 release is named “Ganymede” and included 23 projects representing over 18 million lines of code.
The Eclipse sub-projects are grouped into 10 major project areas that include:
• The Eclipse Platform
• Eclipse Technology
• Business Intelligence and Reporting Tools
• Data Tools Platform
• Device Software Development Platform (DSDP)
• Modeling
• Service Oriented Architecture
• Development Tools
• Test and Performance Tools Platform
• Eclipse Web Tools Platform
Of particular interest to embedded developers are the Device Software Development Platform (DSDP) and the Development Tools projects. Under Development Tools is the C/C++ Development Tool (CDT) project, which is a major focus of this book and the basis for commercial IDEs using Eclipse.
1.4 So What Is Eclipse, Anyway?
Eclipse itself is not an Integrated Development Environment (IDE). Rather it is a collection of frameworks and tools for building IDEs and complex “rich-client” applications. The Eclipse Foundation’s website describes it as “an extensible development platform, runtimes and application frameworks for building, deploying and managing software across the entire software lifecycle.” One early technical overview paper described it thus: “The Eclipse Platform is an IDE for anything, and for nothing in particular.”
Although Eclipse 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 a specific task.
Eclipse is largely written in Java, and was originally developed for it. Consequently, it runs on any machine with a Java Runtime Environment (JRE). Figure 1.1 shows the platform’s major components and APIs. The platform’s principal role is to provide tool developers with mechanisms to use, and rules to follow, for creating seamlessly integrated tools. These mechanisms are exposed via well defined API interfaces, classes, and methods. The platform also provides useful building blocks and frameworks that facilitate developing new tools.
Figure 1.1: Elements of Eclipse.
Eclipse is designed and built to meet the following requirements:
• Support the construction of a variety of tools for application development.
• Support an unrestricted set of tool providers, including independent software vendors (ISVs).
• Support tools to manipulate arbitrary content types such as HTML, Java, C, JSP, EJB, XML, and GIF.
• Facilitate seamless integration of tools within and across different content types and tool providers.
• Support both GUI and non-GUI-based application development environments.
• Run on a wide range of operating systems, including Windows and Linux.
• Capitalize on the popularity of the Java programming language for writing tools.
1.4.1 Workbench
The workbench is the primary user interface for Eclipse. As such, it implements the Eclipse “personality” and supplies the structures that allow tools to 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 you see when Eclipse is running.
The workbench, in turn, is implemented on top of two generic toolkits:
• Standard Widget Toolkit (SWT). A widget set and graphics library integrated with the native window system, but with an OS-independent API.
• JFace. A UI toolkit implemented using SWT that simplifies common UI programming tasks.
SWT provides a common API that works across a number of supported windowing systems. For each native windowing system, SWT translates its common API into native window widgets. Most common low-level widgets such as lists, text fields, and buttons are implemented natively. But some generally useful higher-level widgets, such as toolbars and trees, may need to be emulated on some window systems. The end result is that SWT maintains a consistent programming model in all environments, while preserving the look and feel of the underlying native window system. Thus, Eclipse on a Mac looks like a Mac OS application, Eclipse under Windows XP (or Vista if you prefer) looks like a Windows application, and so on.
JFace is a UI toolkit providing classes for handling many common UI programming tasks such as image and font registries, dialog, preference, and wizard frameworks, and progress reporting for long running operations. It sits on top of SWT and thus is independent of the native windowing system.
1.4.2 Workspaces
The various tools plugged in to the Eclipse Platform operate on regular files in your workspace. The workspace consists of one or more top-level projects, where each project maps to a corresponding 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.
It is also possible to have multiple workspaces. You specify a workspace when starting Eclipse. From within Eclipse you can also change workspaces, which causes Eclipse to restart itself.
A project contains files that you create and modify. In addition to being accessible from Eclipse, all files in the workspace are directly accessible to the standard programs and tools provided by the underlying operating system. Tools integrated with the Platform are provided with APIs for dealing with workspace resources (the collective term for projects, files, and folders). So-called adaptable objects represent workspace resources so that other parties can extend their behavior.
In a large project, the Linux kernel, for example, tools like compilers and link checkers must apply a coordinated analysis and transformation of thousands of separate files. To this end the platform provides an incremental project builder framework; the input to an incremental build is a resource tree delta capturing the net resource differences since the last build. The platform allows several different incremental project builders to be registered on the same project and provides ways to trigger project and workspace-wide builds. An optional workspace auto-build feature automatically triggers the necessary builds after each resource modification operation (or batch of operations).