Table Of ContentEARLY ACCESS PROGRAM CHAPTER
Eclipse in Action: A Guide for Web Developers
by David Gallardo, Ed Burnette and Robert McGovern
Copyright 2003 Manning Publications
contents
PART I USING ECLIPSE
Chapter 1 ■ Overview
Chapter 2 ■ Getting started with the Eclipse Workbench
Chapter 3 ■ The Java development cycle: test, code, repeat
Chapter 4 ■ Working with source code in Eclipse
Chapter 5 ■ Building with Ant
Chapter 6 ■ Source control with CVS
Chapter 7 ■ Web development tools
PART II EXTENDING ECLIPSE
Chapter 8 ■ Introduction to Eclipse plug-ins
Chapter 9 ■ Working with plug-ins in Eclipse
Appendix A ■ Java perspective menu reference
Appendix B ■ CVS installation procedures
Appendix C ■ Plug-in extension points
Appendix D ■ Introduction to SWT
Appendix E ■ Introduction to JFace
iii
1
Overview
In this chapter…
■ A brief history of Eclipse
■ The Eclipse.org consortium
■ An overview of Eclipse and its design
■ A peek at the future
3
4 CHAPTER 1
Overview
Many blacksmiths take pride in making their own tools. When first starting out
in the trade, or when undertaking a job that has special requirements, making
new tools is the first step. Using forge, anvil, and hammer, the blacksmith
repeats the cycle of heating, hammering, and cooling the steel until it becomes a
tool of exactly the right shape, size, and strength for the job at hand.
Software development seems like a clean and abstract process when com-
pared to the visceral force and heat of blacksmithing. But what code has in com-
mon with metal (at least at high temperatures) is malleability: With sufficient
skill and effort, you can bang code or steel into a finely honed tool or a massive
architectural wonder.
Eclipse is the software developer’s equivalent to the blacksmith’s workshop,
initially equipped with forge, anvil, and hammer. Just as the blacksmith might
use his existing tools to make a new tool, perhaps a pair of tongs, you can use
Eclipse to build new tools for developing software—tools that extend the func-
tionality of Eclipse. One of Eclipse’s distinguishing features is its extensibility.
But don’t be put off by this do-it-yourself ethos; you don’t need to build your
own tools to take full advantage of Eclipse. You may not even need any new tools;
Eclipse comes with a fully featured Java development environment, including a
source-level debugger. In addition, because of Eclipse’s popularity and its open-
source nature, many specialized tools (built for Eclipse, using Eclipse) are
already freely available (some of which you’ll be introduced to in this book), and
many more are on the way.
1.1 Where Eclipse came from
It would be incredible for a software development environment as full-featured
and mature as Eclipse to appear out of the blue. But that is what seemed to have
happened when version 1.0 was released in November 2001. Naturally, there was
some carping about the approach Eclipse took and the features it lacked. Since
the days of emacs, one of the two most popular sports among developers has
been debating which development environment is the best. (The other is debat-
ing which operating system is the best.) Surprisingly, there was little of the usual
contentiousness this time. The consensus seemed to be that Eclipse was almost,
but not quite there yet; what version 1.0 product is?
Some companies are famously known for not getting things right until ver-
sion 3.0 (and even then you’re well advised to wait for 3.1, so the serious bugs get
shaken out). But though Eclipse 1.0 lacked some features and didn’t quite accom-
modate everyone’s way of working, it was apparent that Eclipse got things right.
Where Eclipse came from 5
Best of all, it was a free, open source project with a lot of resources. It was also
apparent that Eclipse’s developers were listening to the users—indeed, the devel-
opers themselves were the biggest users of Eclipse. When version 2.1 arrived in
March 2003, it met or surpassed almost everyone’s high hopes—so many people
rushed to download it that it was nearly impossible to get a copy for the first
week of release.
1.1.1 A bit of background
Eclipse wasn’t a happy accident of engineering, of course; IBM reportedly spent
more than $40 million developing it before giving it away as open source soft-
ware to a consortium, Eclipse.org, which initially included Borland, IBM, Merant,
QNX Software Systems, Rational Software, Red Hat, SuSE, TogetherSoft, and Web-
gain. Other companies that have since joined include Hewlett Packard, Fujitsu,
Oracle, and Sybase. IBM continues to take the lead in Eclipse’s development
through its subsidiary, Object Technologies International (OTI), the people who
developed Eclipse in the first place.
OTI is a distinguished developer of object-oriented development tools, with a
history going back to 1988, when the object-oriented language of choice was
Smalltalk. OTI, acquired by IBM in 1996, was the force behind IBM’s Visual Age
products, which set the standard for object-oriented development tools. Many
concepts pioneered in Smalltalk were applied to Java, making Visual Age for
Java (VA4J) a unique environment. For example, it had no concept of a file; ver-
sioning took place at the method level. Like the other Visual Age products, VA4J
was originally written in Smalltalk.
Eclipse is essentially a rewrite of VA4Java in Java. Smalltalk-like features,
which made VA4J seem quirky compared to other Java IDEs, are mostly gone.
Some OO purists are disappointed, but one of the things that has made Java
popular is its willingness to meet practicalities halfway. Like a good translation,
Eclipse is true to the spirit of its new language and strikes a similar balance
between ideology and utility.
1.1.2 The Eclipse organization
The Eclipse project is managed and directed by the consortium’s Board of Stew-
ards, which includes one representative from each of the consortium’s corporate
members. The board determines the goals and objectives of the project, guided
by two principal objectives that it seeks to balance: fostering a healthy open
source community and creating commercial opportunities for its members.
6 CHAPTER 1
Overview
At the operational level, the Eclipse project is managed by the Project Man-
agement Committee (PMC), which oversees the project as a whole. The Eclipse
project is divided into three subprojects:
■ The Platform
■ The Java Development Toolkit (JDT; notably led by Erich Gamma, who is well-
known for his work on design patterns and agile development methodology)
■ The Plug-in Development Environment (PDE)
Each of these subprojects is further subdivided into a number of components.
For example, the Platform subproject includes over a dozen components such as
Compare, Help, and Search. The JDT subproject includes three components:
Debug, (which provides debug support for Java), UI, and Core. The PDE sub-
project includes two components: UI and Core.
Contributions to the project are not limited to IBM and consortium members.
As is true with any other open source project, any individual or company is wel-
come to participate and contribute to the project.
1.1.3 Open source software
Many commercial ventures are concerned about the growing influence of open
source development and have done their best to spread fear, uncertainty, and
doubt about this trend. One particularly misleading claim is that open source
licenses are viral in nature—that by incorporating open source code in a com-
mercial product, a company risks losing rights to its proprietary code.
Open source, by definition, is software that grants certain rights to users, nota-
bly the right to the obtain source code and the right to modify and redistribute
the software. These rights are guaranteed by reversing the purpose of copyright
protection. Rather than merely reserving rights for the creator, an open source
license prohibits distribution unless the user is granted these rights. This use of a
copyright is sometimes called a copyleft—all rights reversed.
Although some open source licenses are viral and require that all software
bundled with the open source software be released under the same license, this is
not true of all open source licenses. A number of licenses have been designed to
support both open source and commercial interests and explicitly allow propri-
etary software that is bundled with open source software to be licensed under a
separate, more restrictive license.
Eclipse, specifically, is distributed under such as license: the Common Public
License (CPL). According to the license, it “is intended to facilitate the commer-
What is Eclipse? 7
cial use of the Program.” The CPL is certified as meeting the requirements of an
open source license by the Open Software Initiative (OSI). For more information
about open source licenses, including the CPL, you can visit the OSI web site at
http://www.opensource.org.
Many open source advocates are wary that commercial interests are co-opting
the purpose of the open source movement, and are cynical of companies such as
IBM that are materially aiding open source projects. There is no doubt, however,
that open source software gains legitimacy from the backing of a major corpora-
tion such as IBM. This legitimacy helps dispel some of the weaker claims of
opponents (particularly subjective attacks such as the notion that the software is
hobbyware) and force the argument to remain focused on more substantial
issues, such as performance and security.
A number of projects, including Mozilla, Apache, and now Eclipse, demonstrate
that both commercial and free software can benefit from being open source.
There are several reasons, but in particular, a successful open source project cre-
ates value for everyone.
In the case of Eclipse, there is another, more tangible reason: Eclipse creates
an entire new market. Making Eclipse the best-designed open and extensible
framework is like building a town market. Vendors and buyers large and small
will be drawn together on market day.
1.2 What is Eclipse?
So far we’ve alluded to Eclipse in metaphorical terms, comparing it to a black-
smith’s shop, where you can not only make products, but also make the tools for
making the products. In practical terms, that’s probably a fair comparison. When
you download the Eclipse SDK, you get a Java Development Toolkit (JDT) for
writing and debugging Java programs and the Plug-in Development Environ-
ment (PDE) for extending Eclipse. If all you want is a Java IDE, you don’t need
anything besides the JDT; ignore the PDE, and you’re good to go. This is what
most people use Eclipse for, and the first part of this book focuses entirely on
using Eclipse as a Java IDE.
The JDT, however, is an addition to Eclipse. At the most fundamental level,
Eclipse is the Eclipse Platform. The Eclipse Platform’s purpose is to provide the
services necessary for integrating software development tools, which are imple-
mented as Eclipse plug-ins. To be useful, the Platform has to be extended with
plug-ins such as the JDT. The beauty of Eclipse’s design is that, except for a small
runtime kernel, everything is a plug-in or a set of related plug-ins. So, whereas
8 CHAPTER 1
Overview
the Eclipse SDK is like the blacksmith’s shop, the Eclipse Platform it is based on
is more like an empty workshop, with nothing but electrical, water, and gas hook-
ups. If you’d rather be a potter than a blacksmith, then install a kiln and a potter’s
wheel, get some clay, and start throwing pots. If you only want to use Eclipse for
C/C++ development, then replace the JDT with the C Development Toolkit (CDT).
This plug-in design makes Eclipse extensible. More important, however, the
platform provides a well-defined way for plug-ins to work together (by means of
extension points and contributions), so new features can be added not only easily
but seamlessly. As you perform different tasks using Eclipse, it is usually impossi-
ble to tell where one plug-in ends and another begins.
1.2.1 The Eclipse architecture
In addition to the small platform runtime kernel, the Eclipse Platform consists of
the Workbench, workspace, help, and team components. Other tools plug in to
this basic framework to create a usable application. (See figure 1.1.)
The Platform runtime
The primary job of the Platform runtime is to discover what plug-ins are avail-
able in the Eclipse plug-in directory. Each plug-in has an XML manifest file that
lists the connections the plug-in requires. These include the extension points it
provides to other plug-ins, and the extension points from other plug-ins that it
requires. Because the number of plug-ins is potentially large, plug-ins are not
loaded until they are actually required, to minimize start-up time and resource
Figure 1.1
The Eclipse architecture.
Except for a small runtime
kernel, everything in
Eclipse is a plug-in or a
set of related plug-ins.
What is Eclipse? 9
requirements. The second part of this book focuses on the architecture of plug-ins,
additional details about how they work, and how to develop them using the PDE.
The workspace
The workspace is responsible for managing the user’s resources, which are orga-
nized into one or more projects at the top level. Each project corresponds to a
subdirectory of Eclipse’s workspace directory. Each project can contain files and
folders; normally each folder corresponds to a subdirectory of the project direc-
tory, but a folder can also be linked to a directory anywhere in the filesystem.
The workspace maintains a low-level history of changes to each resource. This
makes it possible to undo changes immediately, as well as revert to a previously
saved state—possibly days old, depending on how the user has configured the
history settings. This history also minimizes the risk of losing resources.
The workspace is also responsible for notifying interested tools about changes
to the workspace resources. Tools have the ability to tag projects with a project
nature—as a Java project, for example—and can provide code to configure the
project’s resources as necessary.
The Workbench
The Workbench is Eclipse’s graphical user interface. In addition to displaying the
familiar menus and toolbars, it is organized into perspectives containing views,
and editors. These are discussed in chapter 2.
One of the Workbench’s notable features is that, unlike most Java applications,
it looks and feels like a native application. This is the case because it is built using
Eclipse’s Standard Widget Toolkit (SWT) and JFace, a user interface toolkit built
on top of SWT. Unlike the standard Java graphics APIs, AWT and Swing, which
emulate the native graphics toolkit, SWT maps directly to the operating system’s
native graphics.
SWT is one of the most controversial aspects of Eclipse, because SWT must be
ported to each platform that Eclipse supports. As a practical matter, this isn’t a
serious concern, because SWT has already been ported to the most popular plat-
forms (including Windows, Linux/Motif, Linux/GTK2, Solaris, QNX, AIX, HP-UX,
and Mac OS X).
It is possible to use SWT and JFace to create your own native-looking Java appli-
cations. An introduction to programming with SWT is found in appendix D of this
book, and a brief overview of JFace is presented in appendix E. Note that Eclipse’s
use of SWT/JFace doesn’t force you to use it in your applications; unless you are
writing a plug-in for Eclipse, you can continue to program with AWT/Swing as usual.
