| The WSAD product has emerged in the last two years as IBM's flagship integrated development environment (IDE) platform for J2EE application development. From a simple stand-alone Java program to a multi-tiered, distributed, team-oriented, enterprise class application, WSAD provides the tools necessary to build, test, and deploy almost any conceivable J2EE application. In what follows , we will refer to the most recent WSAD version at the time of this edition, WSAD V5.0. WSAD and Eclipse IBM took an interesting and, in our view, bold step during the early development of the WSAD product line. The core of the WSAD IDE platform was released as an open -source software project, called Eclipse (www.eclipse.org). The Eclipse software (largely written in Java itself) provides the framework to create an IDE for almost any type of application development. This is the heart of the Eclipse design. As stated on the Web site: "The Eclipse Platform is an IDE for anything, and for nothing in particular." The Eclipse software package is not just an inert framework. The download includes the basic IDE framework and components (editor, builder) for Java development, so it is a capable Java IDE to start with. But it is its ability to accept various add-in components ("plug-ins") that give Eclipse its power. Any one or any organization or company can develop a tool for Java, WebSphere, or Domino development and offer it as an Eclipse plug-in developers can use. IBM's motives behind the Eclipse project are an interesting topic for discussion on their own. We will resist this urge except to cite one that we believe is important in the context of WebSphere and Domino development. It is the Eclipse architecture of tools and plug-ins that IBM wanted to expose to developers and get them writing software for. A tool written for Eclipse is a tool that will work with WSAD. We will discuss below how IBM itself has utilized the Eclipse tool plug-in architecture to provide Domino development functions within WSAD. Eclipse is written in Java, and the plug-ins are Java entities delivered in a .jar (Java Archive) file. The actual connection between a plug-in and Eclipse is described in an XML file. This file carries information, such as which other plug-ins this plug-in depends on, which extension point the plug-in connects to (where it hooks into Eclipse), or which classes within the plug-in are associated with each extension point. In short, the XML file defines how the plug-in will be bound to the Eclipse environment. Each plug-in is stored in its own folder within a special plug-ins directory. When Eclipse starts up, it traverses this directory, reading all the XML files and building an internal registry of all available plug-ins. The plug-ins are not loaded from the start, but are instead loaded only when needed. Once a plug-in is activated, it is never removed. With this plug-in format, Eclipse 2.1 can deduce how plug-ins are hooked in without having to load any Java code. Consequently, Eclipse launches more quickly than it otherwise would. And because an Eclipse plug-in has no life cycle, you avoid complex life-cycle management issues. Because multiple plug-ins can attach to a given extension point, however, it also means that the first time an action requires one or more plug-ins to be activated, response can be slow as Eclipse activates the series of "attached" plug-ins. In addition, a running Eclipse session will consume more and more memory as plug-ins are loaded over time; however, the Java VM (virtual machine) garbage collector will mitigate the forever-upward memory usage. Eclipse Plugin Central, a portal where developers can find Eclipse-based software tools, is located at http://www.eclipseplugincentral.com. |
