Eclipse 101

It is beyond the scope of this book to delve deeply into the Eclipse implementation details, but a basic overview is useful to understand how WebSphere Studio is assembled. Additional details along with freely downloadable Eclipse builds are available on the Eclipse web site, http://www.eclipse.org/.

Eclipse is implemented in Java, and provides a number of common services. These include the basic user interface framework, which means that the behavior of the various windows and controls in any Eclipse tool will be consistent. Although the underlying implementation is Java, Eclipse uses its own Standard Widget Toolkit (SWT) user interface widget set, which provides a Java interface for the underlying native platform widgets and controls. Thus, Eclipse does not look like a Java application; it looks and feels like a native application on all supported platforms.

Another advantage of the Eclipse framework is that it provides a common definition for things such as resources, projects, and preferences. This means that an Eclipse project is the same project, regardless of which tool or mechanism is used to interact with it. The days of having to export data from one tool, and import it into a different tool (typically loosing your original tool and project settings in the process), are over with the use of Eclipse.

The thing that makes Eclipse so interesting to tool builders, however, is the ability to dynamically add new functions, via the Eclipse plug-in mechanism. Eclipse plug-ins are different from application server plug-ins, although the goal of supporting the dynamic addition of function is the same. An Eclipse plug-in consists a set of Java classes that actually implement the desired function, and a definition file (plugin.xml), which is used to register the plug-in, as well as declare how the plug-in depends on, extends, and interacts with other plug-ins.

Eclipse itself has a very small core, which provides little more than the ability to register, activate, and invoke plug-ins. The majority of the functions that are in the base Eclipse platform, and all functions that are added to form WebSphere Studio, are provided by plug-ins. Previous tools (such as VisualAge for Java) provided limited extension mechanisms that could only add to a single menu item. In contrast, Eclipse allows every aspect of the user interface and the underlying behavior to be defined and extended via plug-ins. The result of this design decision is that it is possible to tightly couple a new plug-in into the existing platform, giving comprehensive UI integration, data integration, and task-flow integration:

Eclipse dynamically detects plug-ins when it starts, and the plug-in registration mechanism consists of no more than the existence of a plug-in in the right directory and the right form. This means that the assembly of a product based on Eclipse can be done in a very modular fashion as the product is packaged. The entire environment does not need to be re-built simply to add or remove one piece of function; all that is required is the inclusion of the correct set of plug-ins. This is how WebSphere Studio is built, and the result is an entirely consistent family of products; the more advanced configurations simply include more plug-ins, but no changes are required to any of the base plug-ins, and so there is no change to the core behavior as you move from one configuration to another. You get more function as you go, but what is common, stays common.

As WebSphere Studio is built on Eclipse, it also contains all the new functions and features that are being added to the base open source version. WebSphere Studio version 4.0 was built on top of Eclipse 1.0, and version 5.0 is built on Eclipse 2.0. Subsequent versions of WebSphere Studio will continue to use newer versions of Eclipse, and this cross pollination is mutually beneficial – WebSphere Studio requirements will drive new functionality into Eclipse, and other improvements implemented in Eclipse will also appear in the new versions of WebSphere.