The typical relationship between the programmer and the programming environment is one where the environment nurtures the programmer. In return for this support, the programmer works within the constraints created by the environment.
In the early seventies, Smalltalk was written with a different philosophy. Every user of every application was considered a potential programmer. The classic example is, you could be editing a document and decide you didn't like how the editor worked. Pressing a button would show you the inner workings of the document editor and provide you with tools to change the editor's behavior.
User-as-programmer may seem far-fetched, but Smalltalk saw many cases where non-programming professionals wrote applications uniquely suited to their own needs by learning programming a little at a time and by example. The key to enabling user programming is to structure the environment to encourage learning, giving the user a little payoff for a little investment and a little more payoff for a little more investment.
Eclipse structures the computing experience similarly. Its goals are much the same as the goals of Smalltalk: Give the users an empowering computing experience and provide a learning environment as a path to greater power. In Eclipse, moving up the pyramid requires investment and will be attempted by fewer people (see Figure 1.1).
Users—. Daily Eclipse users. Currently this is restricted to programmers, but there is no reason in principle why Eclipse couldn't be used to structure other computing work.
Configurers—. Users who customize their experience of Eclipse, either by rearranging perspectives, setting preferences, or deciding which views to show. Configuration is limited to changes envisioned by the original programmer.
Extenders—. Programmers who make changes not envisioned by the original Eclipse programmers. Eclipse provides a rich set of places to “plug in” new functionality, because Eclipse itself is built entirely by plugging in functionality.
Publishers—. Once you've written something useful, other folks may want it, too. Eclipse is consciously structured so you can easily bundle together extensions so others can load them.
Enablers—. Eclipse is built out of “places-to-plug-functionality-in” (extension points) and “functionality-to-be-plugged-in” (extensions). Once you have published a contribution, the next step is to enable others to extend it in ways you don't foresee. You do this by publishing your extension points.
Committers—. Eclipse is an open source project. If there is a change you want to make that is outside the scope of the available extension points, you can change the source code itself. Getting your changes incorporated into the global Eclipse release requires that you gain the trust of the existing community of committers. Becoming a committer is outside the scope of this book, although we will look at lots of the Eclipse source code so you can get an idea of what would be involved.
We can also map these levels onto a circle as shown in Figure 1.2.
What makes this circle interesting is the final arrow, from Enabler back to User. In Eclipse, you don't just invest more and more and receive more and more. When you take the step to become an enabler with your own extension points, you create for yourself the opportunity to be nourished by the work of others. Sometime later, someone may extend your contribution in ways you find useful. By creating and sharing your own extension points you can get the benefit of their work without further effort on your part.
We intend for this book to be your guide around the Contribution Circle.
We've been talking about writing a book together for nearly a decade. We share an interest in software design, in the design of software for widespread adaptation (frameworks), and in discovering the “universal” rules that lie behind design. We first met at Bruce Anderson's Architecture Handbook workshop at OOPSLA-93 in Washington, D.C, where we began discussing software design. We discovered that, while we generally shared a common aesthetic of design, we disagreed in enough interesting ways to fuel years of debate and joint exploration. The chance to write this book gave us a good reason to continue and deepen our discussion of design.
We want to help you around the Contribution Circle as far as you want to go. For you to learn your way around the circle to become a enabler, we need to help you learn two things:
About Eclipse. There is far more to Eclipse than would fit into any ten books, but there are some basic concepts and details you simply cannot live without. By following the examples here, you will see these basics in action.
Learning about Eclipse. We aren't going to pretend that we have memorized all the details of Eclipse. When we program in Eclipse, we search for examples from which to copy. As we develop our code, we'll tell you how we found our examples.
Design principles. Okay, this is our secret third agenda. As we go along, we'll tell you about the underlying principles of design behind the structure of Eclipse in particular, but also behind platforms of all kinds.
Pedagogical Structure
When we want to describe an Eclipse concept, we will always place it in the context of our example application. We'll start with the idea of what feature we want to add, describe the general concept in Eclipse that fits the idea best, show an example in Eclipse that uses that concept, show how the concept is used in our example, then give forwarding pointers to other places in Eclipse you can look for more examples. This is how we develop in Eclipse ourselves, by copying examples, so it's good practice to see it here.
The book is organized as four concentric circles, each taking you around the Contribution Circle in increasing detail.
Circle Zero, Chapter 2 and Chapter 3, gets you set up for plug-in development and takes you as quickly as possible from a tiny plug-in idea to its implementation.
Circle One, Chapter 4 through Chapter 12, introduces the content of our plug-in and running test cases, and makes and deploys the simplest possible test-running plug-in.
Circle Two, Chapter 13 through Chapter 30, takes the basic test-running plug-in and adds all the capabilities expected of Eclipse contributions, acquiring an interesting twist of metaphor halfway through.
Circle Three, Chapter 31 through Chapter 37, tours Eclipse designer-to-designer, highlighting areas of Eclipse worth exploring early. These essays use design and implementation patterns as their basic vocabulary, showing how the patterns play out in a variety of contexts.
Because this chapter and the following chapters constitute a complete circle, we should have a little bit of background about the plug-in architecture of Eclipse. Eclipse is a collection of places-to-plug-things-in (extension points) and things-plugged-in (extensions). The powerstrip is a kind of extension point. Multiple extensions (in this case, power plugs) can plug into it, and although the extensions are different shapes and have different purposes, they all must share a common interface.
Here is a bit of the Eclipse architecture to get you started. Then we will start programming. We get back to some key architectural elements of Eclipse in Circle Three. If you are more comfortable having an overall picture before looking at details, you may want to read Circle Three now.
Figure 1.3 shows the three layers of Eclipse.
Platform—. The Eclipse platform defines the common programming-language-neutral infrastructure.
Java Development Tools (JDT)—. The Java development tools add a full-featured Java IDE to Eclipse.
Plug-In Development Environment (PDE)—. The PDE extends the JDT with support for developing plug-ins.
The platform consists of several key components that are layered into a user interface (UI)-independent core and a UI layer, as shown in Figure 1.4.
Runtime—. The run-time component defines the plug-in infrastructure. It discovers the available plug-ins on start-up and manages the plug-in loading.
Workspace—. A workspace manages one or more top-level projects. A project consists of file and folders that map onto the underlying file system.
Standard Widget Toolkit (SWT)—. The SWT provides graphics and defines a standard set of widgets.
JFace—. A set of smaller UI frameworks built on top of SWT supporting common UI tasks.
Workbench—. The workbench defines the Eclipse UI paradigm. It centers around editors, views, and perspectives.
Let's take a brief look at the workbench and its components, shown in Figure 1.5.
The Eclipse workbench is presented in one or more windows. A workbench window contains a set of workbench parts. These can be either views or editors. A perspective defines the visual arrangement of the workbench parts.
Finally, since you are about to start extending Eclipse, you should familiarize yourselves with the Eclipse UI guidelines.[1]