Preface

When we were first exposed to Eclipse back in late 1999, we were struck by the magnitude of the problem IBM was trying to solve. IBM wanted to unify all its development environments on a single code base. At the time, the company was using a mix of technology composed of a hodgepodge of C/C++, Java, and Smalltalk.

Many of IBM’s most important tools, including the award-winning Visual-Age for Java IDE, were actually written in Smalltalk—a wonderful language for building sophisticated tools, but one that was rapidly losing market share to languages like Java. While IBM had one of the world’s largest collections of Smalltalk developers, there wasn’t a great deal of industry support for it outside of IBM, and very few independent software vendors (ISVs) were qualified to create Smalltalk-based add-ons.

Meanwhile, Java was winning the hearts and minds of developers worldwide with its promise of easy portability across a wide range of platforms, while providing the rich application programming interface (API) needed to build the latest generation of Web-based business applications. More important, Java was an object-oriented (OO) language, which meant that IBM could leverage the large body of highly skilled object-oriented developers it had built up over the years of creating Smalltalk-based tools. In fact, IBM took its premier Object Technology International (OTI) group, which had been responsible for creating IBM’s VisualAge Smalltalk and VisualAge Java environments (VisualAge Smalltalk was the first of the VisualAge brand family, and VisualAge Java was built using it), and tasked the group with creating a highly extensible integrated development environment (IDE) construction set based in Java. Eclipse was the happy result.

OTI was able to apply its highly evolved OO skills to produce an IDE unmatched in power, flexibility, and extensibility. The group was able to replicate most of the features that had made Smalltalk-based IDEs so popular the decade before, while simultaneously pushing the state of the art in IDE development ahead by an order of magnitude.

The Java world had never seen anything as powerful or as compelling as Eclipse, and it now stands, with Microsoft’s .NET, as one of the world’s premier development environments. That alone makes Eclipse a perfect platform for developers wishing to get their tools out to as wide an audience as possible. The fact that Eclipse is completely free and open source is icing on the cake. An open, extensible IDE base that is available for free to anyone with a computer is a powerful motivator to the prospective tool developer.

It certainly was to us. At Instantiations and earlier at ObjectShare, we had spent the better part of a decade as entrepreneurs focused on building add-on tools for various IDEs. We had started with building add-ons for Digitalk’s Smalltalk/V, migrated to developing tools for IBM’s VisualAge Smalltalk, and eventually ended up creating tools for IBM’s VisualAge Java (including our award-winning VA Assist product and our jFactor product, one of the world’s first Java refactoring tools). Every one of these environments provided a means to extend the IDE, but they were generally not well documented and certainly not standardized in any way. Small market shares (relative to tools such as VisualBasic) and an eclectic user base also afflicted these environments and, by extension, us.

As an Advanced IBM Business Partner, we were fortunate to have built a long and trusting relationship with the folks at IBM responsible for the creation of Eclipse. That relationship meant that we were in a unique position to be briefed on the technology and to start using it on a daily basis nearly a year-and-a-half before the rest of the world even heard about it. When IBM finally announced Eclipse to the world in mid-2001, our team at Instantiations had built some of the first demo applications IBM had to show. Later that year, when IBM released its first Eclipse-based commercial tool, WebSphere Studio Application Developer v4.0 (v4.0 so that it synchronized with its then-current VisualAge for Java v4.0), our CodePro product became the very first commercial add-on available for it (and for Eclipse in general) on the same day. Two years later, we introduced our first GEF-based tool, WindowBuilder Pro, a powerful graphical user interface (GUI) development tool.

Developing WindowBuilder over the last several years has provided us with an opportunity to learn the details of Eclipse GEF development at a level matched by very few others. WindowBuilder has also served as a testbed for many of the ideas and techniques presented in this book, providing us with a unique perspective from which to write.

WindowBuilder’s product suite (especially GWT Designer) caught the attention of Google, which acquired Instantiations in August of 2010. Since the acquisition Google has donated the WindowBuilder architecture and the two projects, SWT Designer and Swing Designer, to the Eclipse Foundation. The GWT Designer product has been folded into the Google Plug-in for Eclipse (GPE).

Goals of the Book

This book provides an in-depth description of the process involved in building Eclipse GEF-based tools and editors. This book has several complementary goals:

• To provide a quick introduction to GEF for new users

• To provide a reference for experienced Eclipse GEF users wishing to expand their knowledge and improve the quality of their GEF-based products

• To provide a detailed tutorial on creating sophisticated GEF tools suitable for new and experienced users

The first chapter introduces GEF, Draw2D, and Zest and includes examples of what has been built using GEF. The next two chapters outline the process of building a simple Draw2D example. The intention of these chapters is to help developers new to GEF quickly understand and pull together an example they can use to experiment with.

The next five chapters progressively introduce the reader to more and more of the Draw2D framework that forms the foundation of GEF. The fourth chapter introduces figures, which are the building blocks for the rest of the book. Chapters 5 through 8 bring the user through the complete Draw2D Genealogy example, introducing concepts such as layout managers, connections, layers, and viewports.

The ninth chapter presents Zest, a graph visualization project part of GEF.

The remaining chapters present the non-Draw2D portions of the GEF project, including EditParts, EditPolicies, tools, commands, and actions. These chapters walk the user through the development of a GEF Editor for a genealogy model.

Each chapter focuses on a different aspect of the topic and includes an overview, a detailed description, a discussion of challenges and solutions, diagrams, screenshots, cookbook-style code examples, relevant API listings, and a summary.

Sometimes a developer needs a quick solution, while at other times that same developer needs to gain in-depth knowledge about a particular aspect of development. The intent is to provide several different ways for the reader to absorb and use the information so that both needs can be addressed. Relevant APIs are included in several of the chapters so that the book can be used as a standalone reference during development without requiring the reader to look up those APIs in the IDE. Most API descriptions are copied or paraphrased from the Eclipse platform Javadoc.

The examples provided in the chapters describe building various aspects of a concrete Eclipse GEF-based plug-in that will evolve over the course of the book. When you use the book as a reference rather than read it cover to cover, you will typically start to look in one chapter for issues that are covered in another. To facilitate this type of searching, every chapter contains numerous cross-references to related material that appears in other chapters.

Intended Audience

The audience for this book includes Java tool developers wishing to build graphical editing products that integrate with Eclipse and other Eclipse-based products, relatively advanced Eclipse users wishing to build their own graphical tools, or anyone who is curious about what makes Eclipse GEF tick. You should be a moderately experienced Eclipse developer to take full advantage of this book. If you are new to Eclipse or Eclipse plug-in development, we recommend starting with our companion book, Eclipse Plug-ins. We also anticipate that the reader is a fairly seasoned developer with a good grasp of Java and at least a cursory knowledge of extensible markup language (XML).

Conventions Used in This Book

The following formatting conventions are used throughout the book.

Bold—the names of UI elements such as menus, buttons, field labels, tabs, and window titles

Italic—emphasize new terms

Courier—code examples, references to class and method names, and filenames

Courier Bold—emphasize code fragments

“Quoted text”—indicates words to be entered by the user

Acknowledgments

The authors would like to thank all those who have had a hand in putting this book together or who gave us their support and encouragement throughout the many months it took to create.

To our comrades at Instantiations and Google, who gave us the time and encouragement to work on this book: Rick Abbott, Brad Abrams, Brent Caldwell, Devon Carew, David Carlson, David Chandler, Jim Christensen, Taylor Corey, Rajeev Dayal, Dianne Engles, Marta George, Nick Gilman, Seth Hollyman, Alex Humesky, Bruce Johnson, Mark Johnson, Ed Klimas, Tina Kvavle, Florin Malita, Warren Martin, Miguel Méndez, Steve Messick, Alexander Mitin, Gina Nebling, John O’Keefe, Keerti Parthasarathy, Phil Quitslund, Chris Ramsdale, Mark Russell, Rob Ryan, Andrey Sablin, Konstantin Scheglov, Chuck Shawan, Bryan Shepherd, Julie Taylor, Mike Taylor, Solveig Viste, Andrew Wegley, and Brian Wilkerson.

To our editor, Greg Doench, our production editor, Elizabeth Ryan, our copy editor, Barbara Wood, our editorial assistant, Michelle Housley, our marketing manager, Stephane Nakib, and the staff at Pearson, for their encouragement and tremendous efforts in preparing this book for production.

To the series editors, Erich Gamma, Lee Nackman, and John Wiegand, for their thoughtful comments and for their ongoing efforts to make Eclipse the best development environment in the world.

We would also like to thank our wives, Kathy, Helene, and Karen, for their endless patience, and our children, Beth, Lauren, Lee, and David, for their endless inspiration.

About the Authors

Dan Rubel is Senior Software Engineer for Google. He is an entrepreneur and an expert in the design and application of OO technologies with more than 17 years of commercial software development experience, including 15 years of experience with Java and 11 years with Eclipse. He is the architect and product manager for several successful commercial products, including RCP Developer, Window-Tester, jFactor, and jKit, and has played key design and leadership roles in other commercial products such as VA Assist, and CodePro. He has a B.S. from Bucknell and was a cofounder of Instantiations.

Jaime Wren is Software Engineer for Google. He has worked with object-oriented technologies for the last nine years, and Eclipse tools for the past six years, gaining extensive expertise in developing commercial Eclipse-based tools. At Instantiations, Jaime made significant contributions as a developer on the CodePro and WindowBuilder product lines. After the acquisition of Instantiations by Google, he continues to work on the WindowBuilder product on the Google Web Toolkit (GWT) team. Jaime holds a double B.S. in Mathematics and Computer Science from the University of Oregon.

Eric Clayberg is Software Engineering Manager for Google. Eric is a seasoned software technologist, product developer, entrepreneur, and manager with more than 19 years of commercial software development experience, including 14 years of experience with Java and 11 years with Eclipse. He is the primary author and architect of more than a dozen commercial Java and Smalltalk add-on products, including the popular WindowBuilder, CodePro, and the award-winning VA Assist product lines. He has a B.S. from MIT, and an M.B.A. from Harvard, and has cofounded two successful software companies—ObjectShare and Instantiations.

Google is a multinational public corporation invested in Internet search, cloud computing, and advertising technologies. Google hosts and develops a number of Internet-based services and products, and its mission statement from the beguinning has been “to organize the world’s information and make it universally accessible and useful.”

How to Contact Us

While we have made every effort to make sure that the material in this book is timely and accurate, Eclipse is a rapidly moving target, and it is quite possible that you may encounter differences between what we present here and what you experience using Eclipse. The Eclipse UI has evolved considerably over the years, and the latest 3.7 release is no exception. While we have targeted it at Eclipse 3.7 and used it for all of our examples, this book was completed after Eclipse 3.6 was finished and during the final phases of development of Eclipse 3.7. If you are using an older or newer version of Eclipse, this means that you may encounter various views, dialogs, and wizards that are subtly different from the screenshots herein.

• Questions about the book’s technical content should be addressed to [email protected]

• Sales questions should be addressed to Addison-Wesley at www.informit.com/store/sales.aspx

• Source code for the projects presented can be found at www.qualityeclipse.com/projects

• Errata can be found at www.qualityeclipse.com/errata

• Tools used and described can be found at www.qualityeclipse.com/tools