Doug Abbott: Embedded Linux development using Eclipse

Eclipse supports programming teams with facilities for placing projects under the control of version and configuration management tools known as “team repository products.” The Platform has extension points and a repository provider API that allow new kinds of team repositories to be plugged in.

Team repository products invariably affect the user’s workflow, for example, by adding overt steps for retrieving files from the repository, for returning updated files to the repository, and for comparing different file versions. Eclipse allows each team repository provider to define its own workflow so that users already familiar with the native tool can quickly learn to use it from within Eclipse. The platform supplies basic hooks to allow a team repository provider to intervene in certain operations that manipulate resources in a project.

At the UI level, the platform supplies placeholders for certain actions, preferences, and properties, but leaves it to each repository provider to define these UI elements. There is also a simple, extendable configuration wizard that lets users associate projects with repositories, and which permits repository providers to extend with UI elements for collecting information specific to that particular repository.

Multiple team repository products can coexist peacefully within Eclipse. The platform includes built-in support for CVS repositories accessed via pserver, ssh, or extssh protocols.

The Eclipse Platform Help mechanism allows tools (plug-ins) to define and contribute documentation to one or more online books. For example, a tool usually contributes help style documentation to a user’s guide, and API documentation (if any) to a separate programmer’s guide.

Raw content is provided as HTML files. The facilities for arranging the raw content into online books with suitable navigation structures are expressed separately in XML files. This separation allows pre-existing HTML documentation to be incorporated directly into online books without the need to edit or rewrite.

The add-on navigation structure presents the content of the books as a tree of topics. Each topic, including non-leaf topics, can have a link to a raw content page. A single book may have multiple alternate lists of top-level topics allowing some or all of the same information to be presented in completely different organizations. They may be organized by task, or by tool, for example.

The XML navigation files and HTML content files are stored in a plug-in’s root directory or subdirectories. Small tools usually put their help documentation in the same plug-in as the code. Large tools often have separate help plug-ins. The Platform uses its own internal documentation server to provide the actual web pages from within the document web. This custom server allows the Platform to resolve special inter-plug-in links and to extract HTML pages from ZIP archives.

A plug-in is the smallest unit of Eclipse functionality that can be developed and delivered separately. A small tool is usually written as a single plug-in, whereas a complex tool may have its functionality split across several plug-ins. Except for a small kernel known as the Platform Runtime, all of the Eclipse platform’s functionality as described above 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 don’t contain code at all. An 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.

Each plug-in’s configuration is described by a pair of files. The manifest file, manifest.mf, declares essential information about the plug-in to other plug-ins, including the name, version, and dependencies. The second optional file, plugin.xml, declares the plug-in’s 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.

The 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.

On start-up, the Eclipse runtime discovers the set of available plug-ins, reads their manifest files, and builds an in-memory plug-in registry. The platform matches extension declarations by name to their corresponding extension point declarations. Any problems, such as extensions to missing extension points, are detected and logged. The resulting plug-in registry is available via the Platform API. After startup, plug-ins can be unloaded, and new ones installed or new versions of existing plug-ins can replace existing versions.

By default, a plug-in is activated when its code actually needs to be executed. Once activated, a plug-in uses the plug-in registry to discover and access the extensions contributed to its extension points. For example, the plug-in declaring the user preference extension point can discover all contributed user preferences and access their display names to construct a preference dialog. This can be done using only the information from the registry, without having to activate any of the contributing plug-ins. The contributing plug-in will be activated when you select one of its preferences from a list.

By determining the set of available plug-ins up front, and by supporting a significant exchange of information between plug-ins without having to activate any of them, the platform can provide each plug-in with a rich source of pertinent information about the context in which it is operating. The context doesn’t change while the platform is running, so there’s no need for complex life cycle events to inform plug-ins when the context changes. This avoids a lengthy start-up sequence and a common source of bugs stemming from unpredictable plug-in activation order.

The Eclipse platform is potentially useful for just about any software development task you can imagine. The Eclipse Foundation organizes its range of projects and sub-projects under what it calls the “Pillars of Eclipse.” These include:

• Enterprise development . Tools and frameworks that span the entire software development lifecycle, including modeling, development, deployment tools, reporting, data manipulation, testing, and profiling. Projects under this pillar include: Business Intelligence and Reporting Tools (BIRT), Data Tools, Test and Performance Tools, and Web Tools.

• Embedded and device development . This is the area of immediate concern in this book. The projects under this pillar support building embedded applications as well as tools that assist with target management, device debugging, and building GUIs for mobile devices. These include: Device Software Development Platform, Embedded Rich Client Platform, Mobile Tools for Java, Native Application Builder, Target Management, and C/C++ IDE.

• Rich client platform (RCP) . This is a platform for building and deploying so-called “rich client” applications with facilities for deploying native GUI applications to a variety of desktop operating systems, such as Windows, Linux, and Mac OSX. Under this pillar we find Equinox, a component framework based on the OSGi standard, along with the Plug-in Development Environment, Visual Editor, and the Eclipse platform itself.