Table Of Content

EARLY 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 compared to the visceral force and heat of blacksmithing. But what code has in common 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 opensource 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 debating 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 version 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 developers 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 software 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 subproject 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 commercial product, a company risks losing rights to its proprietary code. Open source, by definition, is software that grants certain rights to users, notably 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 proprietary 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 creates 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 blacksmith’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 impossible 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 available 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 organized 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 directory, 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 applications. 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.