The Eclipse Open Source Integrated Development Environment (IDE) (see http://eclipse.org) is rapidly gaining popularity among Java developers primarily because of its excellent Java Development Tools (JDT) and its highly extensible plug-in architecture. Extensibility is, in fact, one of the defining characteristics of Eclipse. As the Eclipse home page says, "Eclipse is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular." Although Eclipse is itself a Java application, all tools, including JDT, are on an equal footing in that they extend the Eclipse platform via well-defined extension points.

Of course, an infinitely extensible, but empty, platform might be interesting to tool vendors, but very boring for developers. Therefore, the initial version of Eclipse came with the JDT and the Plug-in Development Environment (PDE), both examples of how to extend the platform and very useful tools in their own right. JDT supported J2SE development while PDE supported Java-based Eclipse plug-in development. The combination of JDT and PDE fueled the creation of thousands of commercial and Open Source plug-ins for Eclipse, many of which supported J2EE development. For example, IBM released Eclipse-based commercial J2EE products, including WebSphere Studio Application Developer, and Rational Application Developer, while eteration, JBoss, Genuitec, Exadel, and Innoopract among others, released Open Source offerings. However, the profusion of J2EE plug-ins made it difficult for vendors to build on each other and for users to assemble an integrated suite of tools. For example, each J2EE toolset had its own way to support application servers.

As the popularity of Eclipse grew, it became apparent that the next logical step in its evolution was to add platform support for J2EE. This support would provide a common infrastructure for all J2EE plug-ins, with the goal of improving tool integration, reducing plug-in development expense, and simplifying the J2EE development experience for Eclipse users.

In June 2004, based on a proposal from IBM, the Eclipse Management Organization (EMO) agreed to create a new top-level project, the Web Tools Platform (WTP). However, it was believed that for WTP to be truly successful it needed a broad base of vendor support. A search began to engage additional vendors to partner with IBM. WTP was discussed in a BOF session at the first EclipseCon conference held in February 2004, and ObjectWeb agreed to lead the project creation effort. ObjectWeb assembled a set of vendors to join the project and agreed to co-lead the Project Management Committee (PMC). WTP was formally launched in June 2004 based on initial contributions from eteration, Lomboz, and IBM Rational Application Developer.

WTP got further industry endorsement earlier this year when BEA joined the project and announced plans to base a future version of WebLogic Workshop on it. BEA co-leads the PMC along with ObjectWeb. At this year's EclipseCon, Sybase announced the Data Tools Project (DTP), which will add to the data tools in WTP and create a platform layer dedicated to database access. Oracle and Borland also announced Eclipse projects closely related to WTP. With major vendors such as IBM, BEA, Borland, Oracle, and Sybase all co-operating on a shared Open Source tool infrastructure, the center of gravity for J2EE tools has clearly shifted to Eclipse.

WTP 0.7 development is now well underway and has released a series of milestone drivers that can be downloaded from http://eclipse.org/webtools. The final release of WTP 0.7 is on track for a July 2005 delivery. The rest of this article gives you an overview of WTP, its scope, design principles, architecture, ecosystem, and plans.

A Quick Tour of WTP
One way to understand WTP is that it extends Eclipse along two dimensions, namely execution environments and artifact types. The execution environment dimension defines where code runs. Out-of-the-box, Eclipse lets you develop Java main programs that run in a command shell, applets that run in a Web browser, JUnit tests that run in a JUnit runner, and ANT tasks that run in ANT. WTP extends Eclipse by adding servers in general, and both J2EE and database servers in particular, as new execution environments. In general, you need to install an execution environment, configure it in Eclipse, and associate it with development artifacts that you want to run in it.

The development artifact dimension defines what developers create. Obviously, Eclipse majors in Java source code as a primary development artifact. However other artifacts, such as PDE plug-in manifests and Ant build scripts, are also supported. Each artifact type has associated with it builders, creation wizards, syntax-aware editors, validators, semantic search extensions, and refactoring support. Eclipse users expect editors to provide first-class programmer assistance such as code completion, syntax coloring, error markers, and quick fixes. WTP extends Eclipse with support for the large set of new artifact types encountered in J2EE development. These include HTML, CSS, JavaScript, XHTML, JSP, XML, XSD, WSDL, SQL, and all the J2EE deployment descriptors.

One of the key design goals of WTP is to extend Eclipse seamlessly to support these additional execution environments and artifact types. All of the functions that Eclipse users have come to expect from Java source code should "just work" for the new artifacts. For example, if I select a Java main program, I can Run or Debug it. The same should apply to a JSP. When I select it, the Run command should do something sensible. Specifically for a JSP I expect the Run command to somehow deploy my code into a J2EE server and launch a Web browser with the URL for my JSP. Similarly, the Debug command should run my J2EE server in debug mode and the standard Eclipse Debugger should let me step through my JSP source code. My JSP editor should provide code completion for both JSP tags and inlined Java scriptlets. Furthermore, I expect the code completion for Java scriptlets to work exactly like the code completion for Java source files. I don't want to learn new editing commands simply because I'm editing a new artifact type.

WTP 0.7 achieves many of these goals but there is much work to do to support J2EE fully. Consider the problem of refactoring a J2EE application. An operation as simple as renaming a Java class can have many consequences. If the renaming isn't fully rippled through the application, a runtime error can occur. For example, in addition to references from other Java classes, a Java class can be referenced by JSPs and deployment descriptors. All of these artifacts must be updated to reflect the new name. Suppose the Java class is deployed as a Web Service and that WSDL is generated from it. The WSDL may also need to be regenerated. First-class refactoring of J2EE applications will be an ongoing focus for WTP.

Now let's create a JSP version of "Hello, world." If you'd like to follow along, you'll need to do some setup. Download and install the latest stable driver of WTP from the Web site mentioned above. WTP provides support for many popular commercial and Open Source J2EE servers but doesn't include the runtimes. So you also need to install a server on your machine. For purposes of illustration, I'll use Apache Tomcat 5.0.28, which you can obtain from http://jakarta.apache.org/tomcat/. Finally, you'll need a full JDK since JSPs require a Java compiler. I'm using Sun J2SDK 1.4.2_06.

WTP provides a Preference page for Servers. Open the Preference dialog and go to the Server page. Add your Tomcat 5.0 server and configure it to use your JDK (if you use a JRE then JSP compilation will fail). Figure 1 shows the Server Preference page.

Next, create a new Flexible Java Project named Project1 and a new J2EE Web module named Web1 in it. A Flexible Java Project is a J2EE project that can hold several J2EE modules. Figure 2 shows the J2EE Project Explorer after Project1 and Web1 have been created.

Now we're ready to create our JSP. Select the WebContent folder of the Web1 module and use the New File wizard to create a JSP named hello-world.jsp. The wizard fills in the skeleton of a JSP document and opens the file with the JSP editor. The JSP editor has full content assist for HTML and JSP tags, as well as Java scriptlets. Edit the file to say "Hello, world" and save it. Figure 3 shows the JSP editor.