Humans need to feel nurtured and cared for. Humans also need to nurture and care for others. Fulfilling the need to nurture and be nurtured is what makes becoming a fully functioning Eclipse programmer so satisfying. This experience is wrapped in all sorts of rational explanations—“productivity,” “time-to-market,” “leverage.” Eclipse is a productive environment in which to work, and contributing to it makes it more so. The right contributions written by the right person can create a highly leveraged reduction in time-to-market. While these explanations are true, though, they aren't the point.

Working in Eclipse feels good to us because our needs are being taken care of by our environment. When we have a programming problem, there is an Eclipse feature that helps us with it. Contributing to Eclipse feels good to us because we know we are adding to that nurturing feeling of nurturing for ourselves and other programmers. When our contributions enable others to make further contributions of their own, a positive feedback loop appears. That positive feedback feels satisfying.

Contributing to Eclipse also has the potential to become an exciting business proposition. You can use Eclipse to ship fully featured products, or you can ship contributions that extend existing products.

Eclipse is powerful—personally, professionally, and socially. But there is a daunting amount of information necessary to join the cycle of contribution. We hope reading this book will help you get over this initial hurdle and begin contributing.

Eclipse is good news and bad news for developers who like writing tools for developers. The good news is that the platform is incredibly powerful and the internal developers have followed all the rules in creating the Eclipse Java development tools. The bad news is that Eclipse has a strong world view. If you want to play nicely in Eclipse's sandbox, you need to learn the rules.

Beginning with Eclipse feels a bit like parachuting blindfolded into Bangkok (this analogy doesn't apply to Thai programmers). When you land you know you need food and shelter, but how are you going to get it? How can you map your clear desires onto the resources available?

Overcoming this feeling of dislocation is the primary goal of Contributing to Eclipse. If you parachuted into Bangkok with a guide, you could say, “I'm hungry,” and your guide would say, “Here's the kind of place you can get a meal.” Similarly, we can listen to, “I want to build such and so,” and tell you, “This should be its own perspective, that is an object contribution, and you'll need a new editor for that.”

When you are finished with this book, you won't have a complete map of Eclipse, but you'll know at least one place to get each of your basic needs met. You will also know the rules through which you can play well with others. It's as if we draw you a map of Bangkok marked with six streets, a restaurant, and a hotel. You won't know everything, but you'll know enough to survive, and enough to learn more.

When you learn Eclipse, you'll spend much more time reading code than writing code. You will have to grow accustomed to incredibly productive days in which you spend six hours reading and one hour typing. After you become familiar with Eclipse culture, you'll “just know” how to solve more and more problems. However, you'll always solve problems by copying the structure of solutions to similar problems, whether by mimicking Eclipse structure or the structure of your own previous efforts.

As we walk together through our example, we won't pretend that we perfectly remember all the details. Instead, we'll show you how we found structure to mimic. Learning to effectively use Eclipse's search facilities is part of becoming an Eclipse contributor.

This book is not intended for beginners just learning to use Eclipse. We assume a familiarity with the vocabulary of Eclipse—views, editors, and so on. Once you've used Eclipse for a while, you are likely to come up with ideas for extending it. That's when this book comes into play.

When we laid out Contributing to Eclipse, we had a daunting stack of concepts to cover. If we tried to tell you about all 2,000 ideas in Eclipse, though, we would have a book that would cut off the circulation to your lower extremities. In deference to your feet, we've chosen the 50 things that we think are most important for getting you started. Many chapters conclude with “Forward Pointers,” places in the code where you can explore the extension of the concepts covered in the chapter. When we teach Eclipse, this is exactly the structure we use—“Why don't you look at the org.eclipse.core.runtime manifest?”

Once there was a doctoral student who had to take a qualifying exam about fruit. He only had enough time, though, to learn about cucumbers. When the time came for the exam, the first question was, “Tell us about the tomato.” “You see,” he said, “the tomato, like the cucumber, is actually a fruit. The cucumber is 80 percent water, has a disease-resistant skin, and is used in salads.” Every question that came up, he answered with cucumber facts.

We know cucumbers. Except in our case, there are two cucumbers: patterns and JUnit. You'll find pattern-y advice throughout the book. In fact, we were uncomfortable with writing until we started writing the Rules. Once we had the concept of Rules, we could proceed happily. The Rules are really patterns in a micro format.

JUnit, our second cucumber, is the basis for the running example. We wrote JUnit in a few hours in a plane over the Atlantic in 1997. Since then, it seems much of our technical lives have revolved around it. JUnit is fertile ground for an Eclipse example because the core—running tests—is simple but the implications—the presentation of tests and results—have barely been explored.

We did want to warn you, though, that if you're tired of hearing about patterns and JUnit, this is probably not the book for you.