A very simplified definition of Eclipse is that it’s an IDE. Out of the box, it is an excellent Java IDE. However, it goes beyond that. Eclipse is based on modules, called plug-ins, which can extend it beyond just writing code. The number of plug-ins available in the Eclipse community is enormous and they cover diverse functionalities. Using plug-ins, we can write programs in any language, including PHP. We can also use plug-ins to perform any task in our development process, from the idea stage of drawing diagrams to the development stage of writing code to the deployment stage of pushing files to a production server.
For most software applications, we wouldn’t need to care about their history or who develops them. Most IDEs are developed by a commercial company and sold for profit to other developers. For those IDEs, previous versions or incarnations only matter to determine upgrade prices.
However, Eclipse is not your typical software application. It’s not only interesting to know its pedigree, but it’s important as well. Knowing its history and who exactly drives development will help you appreciate Eclipse’s architecture, understand some quirks you may encounter, guide you to the proper place to ask for help, and perhaps inspire you to participate in the community of Eclipse developers.
Before Java, the object oriented language that was all the rage was Smalltalk. Object Technologies International (OTI) specialized in development tools for Smalltalk. Among these tools was Envy, a development environment and source-code manager. In 1996, IBM purchased OTI and made it a subsidiary company. Using Envy as a model, the two companies collaborated to create next generation development tools for languages like Smalltalk (Visual Age for Smalltalk) and Java (Visual Age for Java).
Their next collaboration on development tools began in 1999. Development would occur against the backdrop of two industry trends. First, Linux and open source were emerging as major forces in the industry. Seizing on this, IBM developed a ‘Linux strategy’ and publicly committed $1 billion to marketing Linux and supporting open-source software. Second, in web development, it was clear that typical enterprise web applications often required components to be written in different languages. C++ may be required to access an older data store, SQL may be required to access a more modern database, and JSP may be required to deliver the HTML and JavaScript output. Developers often had to use different programs to write these different portions. IBM wanted to create one unified tool for developers’ needs.
In 2001, after a reported development cost of $40 million, the Eclipse Platform was born, which addressed both these industry trends. IBM reaffirmed its Linux strategy by releasing Eclipse as open-source software to the world, and everyone saw how its architecture allowed unparalleled extensibility.
IBM did not release Eclipse into the cold, harsh world to fend for itself. It created and funded the Eclipse Foundation to act as the custodian of the Eclipse Platform. The Foundation’s Board of Stewards was to steer the direction of Eclipse, oversee development progress, and evangelize the product. Originally, the consortium comprised representatives from Borland, IBM, Merant, Red Hat, SuSE, Rational Software, QNX, TogetherSoft, and Webgain. Over time, other companies such as Oracle, SAP, Ericsson, Hitachi, Fujitsu, and Intel were granted membership.
In February 2004, IBM officially spun off the Foundation and reorganized it as an independent, not-for-profit corporation. The reasoning was that no one company, not even IBM in this case, could meet all the demands of the customers and by setting the Foundation free, Eclipse could become an even better platform for creating integrated tools. This is being achieved today. More contributors have joined in to help with the development of Eclipse, and its independence gives the Foundation more flexibility in collaborating with other companies.
The Foundation currently manages several Eclipse-related open-source projects. These top‑level projects range from business intelligence tools to testing tools and web tools. Underneath each top‑level project are smaller subprojects to break down the work.
|
Originally, there was only one top-level project, the Eclipse project, and its purpose was to manage the IDE that is the subject of this book. That is still the official name for the project despite the use of the word ‘Eclipse’ to mean more of the Foundation, or the platform depending on the context, rather than the IDE product. A counterpart to this is the Apache Foundation. Originally, Apache just meant a web server, but today, the Apache Foundation hosts many more projects in addition to its flagship, the web server. Unlike Eclipse, though, the Apache Foundation has re‑branded the server to ‘Apache HTTP Server’. Thus, barring any similar renaming of the Eclipse IDE, the term ‘Eclipse project’ should be referring to the project in charge of the IDE development and not to the Foundation as a whole or any of the other top‑level projects managed by the Foundation. For simplicity sake, though, unless otherwise stated, when we say ‘Eclipse’ in this book, we’ll mean the Eclipse IDE. |
The Eclipse project is divided into three subprojects — the Platform, Java Development Tools (JDT), and the Plug-in Development Environment (PDE). These three compose the Eclipse Software Development Kit (SDK). The Platform subproject manages the IDE infrastructure and essential services. In other words, the Platform makes the IDE what it is. There are about fifteen smaller component projects underneath the Platform. They include things like Ant integration, the core libraries, the text editor, and the help system. The JDT subproject is in charge of the plug-ins that makes Eclipse a world‑class Java IDE — right out of the box. Three components compose this subproject — the core Java editing environment, debugger, and user interface (UI). The PDE subproject manages the interface that gives Eclipse its incredible extensibility. PDE Build and user interface are the components. As we will soon see, plug-ins are essential to the functionality of Eclipse. The PDE subproject makes interfacing, and thus extending, Eclipse easy. The figure below shows the top-level projects undertaken by the Eclipse Foundation and gives an idea of the sub-projects under the Eclipse Project.
A Project Management Committee (PMC) manages the vision and development of the Eclipse project. The PMC Leader, who is appointed by the Board of Directors, generally selects the PMC. Developers are the volunteers who actually write the Eclipse code.