Eclipse is an open industry platform designed to help designers of servers and client systems develop a variety of Web services. It features a common tool chain to build the necessary high-performance, professional-looking user interfaces and uses an open-source environment with integrated version management, fast incremental resource management and, most importantly, tool integration.

The platform is based on an incremental, extensible approach to tool building, in which everything is a plug-in. A plug-in is a discrete unit of functionality that extends the capabilities of the basic Eclipse platform.

At the heart of the platform's user model is the workspace, which contains resources and a user interface presentation of the workspace called a workbench. This is composed of windows with features such as views, editors and toolbars.

To get a sense of how the system works, consider the project of building a site manager. Broken links annoy and frustrate Web site users and developers. But a site manager is a tool that allows site developers to discover links to and from resources,and ensure that all links lead to someplace interesting and that all interesting places have links leading to them.

We will keep the domain simple. We'll assume that all Web site content is static and that links occur in standard HTML files. The tool must parse the HTML files in a site, identify the links and anchors, and match them up with the other files found on the site. The tool must then expose this information to users so they can better understand and manage their site.

Since the Eclipse platform is domain-independent, it has no understanding of Web site content or semantics. But Eclipse is designed to incrementally extend the platform to add functionality-in this case, for site management.

Building a tool with Eclipse means defining plug-ins, which is done by creating a simple XML manifest file. This markup declares a plug-in whose identification is com.

example.site. All plug-ins must be uniquely identified so they can be referenced by other plug-ins. By convention, plug-in IDs follow Java package naming standards to avoid name space collisions, but the ID of a plug-in need not match the name of an actual package-plug-in code can go in any package.

The tag defines the physical location of the plug-in's code.

All Eclipse plug-ins are written in the Java language. Functionality in other languages must be "wrappered" using JNI or a similar mechanism. The tag specifies the set of plug-ins on which a plug-in depends. In the site manager example we have to manipulate resources and create user interface elements so our plug-in depends on the platform's org.eclipse.core.resources and its org.eclipse.ui plug-ins.

Eclipse uses this information to manage class paths in the platform. That is, you declare the libraries and dependencies for your plug-in and Eclipse automatically computes a virtual class path. This makes all classes in your plug-in's libraries and the libraries of its required plug-ins visible and usable from the plug-in while all other classes are not. This approach keeps the class paths manageable and enables fine-grained control over plug-in activation. Both are key to maintaining performance when hundreds of plug-ins are installed.

The code for finding and storing the relationships among Web site resources is really quite generic-it is largely the same with Eclipse or any other environment. A parser parses the relevant HTML files, extracts all links and anchors, and remembers them in a site map database. In this example we use a simple HTML scanner and our database is actually a java.util.Hashtable.

When the site map is first built, all resources in the site must be analyzed and added to the database. Since scanning a site of 10,000 resources to update the database is slow and unwieldy, subsequent changes should require only incremental database updates rather than a full reanalysis of the site. Using the platform's resource delta and resource change listener mechanisms, it is easy to efficiently track the changes in the resource tree. Installing a listener is a straightforward registration call specifying the listener and the events of interest.

It's not very useful to have a link database to track which links are broken and which resources are orphans unless users can see the information. It's worthwhile to look at some of the major user interface concepts and facilities provided by the platform. The Eclipse platform provides the overall structure and presents an extensible user interface.

The workbench is built from two tool kits. One is the Standard Widget Toolkit (SWT), which provides a common OS-independent API for widgets and graphics implemented using native widgets wherever possible. Where no native widget is available, SWT provides a suitable emulation.

The second is Jface, a user tool kit that handles many common programming tasks. It is window-system-independent and is designed to work with but not obscure SWT. JFace includes the usual user interface tool kit components of image and font registries, dialog, preference and wizard frameworks, and progress reporting for long-running operations and the like.

A view is used to navigate an information hierarchy, open an editor or display object properties. Modifications are saved immediately. An editor is used to edit or browse a resource. Modifications follow an open-save-close life cycle model.

Now let's add menu items, a custom graph view, markers locating link problems and a specialized text editor with HTML structure outlining to the workbench and build a user interface.

To start, we add a "Set Site Location" item to the navigator's context menu. This item is used to specify the URL location of a Web site. Once the location is defined, the site-management tool can distinguish between absolute links within a site and links to other sites. In general, menu and toolbar additions can be made to any view, editor or window in the workbench. Menu items are contributed by plugging an extension into the user interface plug-in's popupMenus extension point.

Every plug-in has the opportunity to say that it can be extended and that it extends other plug-ins. Extension points and extensions are declared in a plug-in's manifest file.

Plug-ins declaring extension points define the requirements placed on plug-ins supplying extensions. A popupMenu extension can be targeted toward a specific part or object type. Here we want to add an action to the context menu for any IProject, in any view, so an objectContribution is used. The objectClass attribute defines the target type and the action subelement defines the item's presentation and the implementation class.

Once this declaration has been made, "Set Site Location" appears in the navigator context menu whenever an IProject is selected. The implementation class, known as the action delegate, is only instantiated if the menu item is actually selected. That is, menu contribution is done completely without code.

D.J. Houghton and Veronika Irvine, staff members at IBM Corp., also contributed.