Eclipse has taken the computing industry by storm. The download data for the Eclipse Software Development Kit (SDK) is astounding and a true ecosystem is forming around this new phenomenon. In this chapter we discuss what Eclipse is and who is involved in it and give you a glimpse of how large a community has put its weight behind this innovative technology.
An open source project would be nothing without a supporting community. The Eclipse ecosystem is a thriving one, with many research projects based on Eclipse, commercial products that ship on top of Eclipse, lively discussions in newsgroups and mailing lists, and a long list of articles and books that address the platform. The following pages will give you a roadmap of the community, so that you will feel more at home as you come to wander its winding streets.
Eclipse means a lot of different things to different people. To some Eclipse is a free, state-of-the-art Java development environment. To others, Eclipse is a flexible environment to experiment with new computer languages or extensions to existing languages. To yet others, Eclipse is a comprehensive framework that deploys many advanced and modern software design and implementation techniques.
The official party line is, Eclipse is an open (IDE) platform for anything, and for nothing in particular. Eclipse is open because its design allows for easy extension by third parties. It is an Integrated Development Environment (IDE) because it provides tooling to manage workspaces; to build, launch and debug applications; to share artifacts with a team and to version code; and to easily customize the programming experience. Eclipse is a platform because it is not a finished application per se but is designed to be extended indefinitely with more and more sophisticated tooling. Eclipse is suitable for anything because it has been used successfully to build environments for wide-ranging topics, such as Java development, Web Services, embedded device programming, and game-programming contests. Eclipse has no particular focus on any vertical domain. The dominance of Java development tooling in Eclipse is merely historical. The platform has no explicit or implicit support whatsoever for Java development as provided by the Java development tools (JDT). The JDT has to play according to the same rules as all the other plug-ins that use the platform.
When this book was being written, Eclipse itself could not read mail yet, but, of course, products based on Eclipse do exist that can read mail. That sums it all up.
Speaking more technically, Eclipse is built on a mechanism for discovering, integrating, and running modules called plug-ins. A contributor to Eclipse delivers as one or more plug-ins an offering that manifests itself with a product-specific user interface (UI) in the workbench. Multiple, usually unrelated, products can be installed in one Eclipse instance and happily live and cooperate to perform a certain task. The class of end products includes IDEs, but also so-called rich clients, applications that benefit from the Eclipse Platform design and its components but do not look like an IDE. Examples of the latter category include the latest generation of applications based on IBM Workplace Client Technology, the first of which will be Lotus Workplace Messaging 2.0 and Lotus Workplace Documents 2.0.
Those who download the generic Eclipse Platform—usually by mistake—are somewhat confounded by what they see. The platform was conceived as the generic foundation for an IDE. That is, the platform is an IDE without any particular programming language in mind. You can create generic projects, edit files in a generic text editor, and share the projects and files with a Concurrent Versions System (CVS) server. The platform is essentially a glorified version of a file-system browser.
As an end user, what you don’t see when you download and run the platform is that the architecture is designed from the ground up for extensibility. In fact, everything you see is a plug-in, and everything you see can be tweaked, replaced, or augmented using various hooks. To draw a computing analogy, it’s like the Internet Protocol (IP): exceedingly generic, not terribly interesting by itself, but a solid foundation on which very interesting applications can be built.
A carefully designed subset of the Eclipse Platform has been produced in Eclipse 3.0: the Rich Client Platform (RCP). Despite the name, this is not the version of the platform sold for fat profits to rich clients. This is the portion of the platform that is interesting for non-development-environment applications. We thought this part so interesting that we dedicated almost half the book to RCP alone.
Eclipse started out as proprietary technology, led by IBM’s subsidiary, Object Technology International (OTI). IBM wanted to reduce the large number of incompatible development environments being offered to its customers and to increase the reuse of the common components in those environments. By using the same common framework, development teams could leverage one another’s components, integrate to a high degree, and allow developers to roam among projects.
Eclipse did not emerge from thin air but evolved from a long product line of development environments, of which the earlier ones are IBM VisualAge for Smalltalk and IBM VisualAge for Java. Both of these products were written in Smalltalk. The IBM VisualAge Micro Edition product was the first serious—and actually quite successful—experiment with writing the entire IDE in Java. Many concepts found in Eclipse have been tried out in that product already. However, for third parties, it proved difficult to extend the product with new components, mainly for two reasons: (1) it was not designed with a component model in mind, and (2) it essentially was a monolithic, closed-source product.
A small team of experts set out to take the experiences of the previous years of designing and implementing development environments. The result was Eclipse, a platform designed from the ground up as an integration platform for development tools. It enabled partners to easily extend products built on it, using the plug-in mechanisms provided by the platform. The subsequent path to open source and enabling of a much wider audience and ecosystem was a natural progression.
The Eclipse open source project was announced in November 2001 by a group of companies that formed the initial Eclipse Consortium. From there, the small initial project burgeoned into a collection of related projects that formed the basis of dozens of commercial applications.
From a small IBM-led project, Eclipse has grown into a framework deployed by a wide assortment of commercial backers. The Eclipse Foundation is a true open source project, with a board of directors governing the direction of the core platform and an ever-growing number of technologies and projects built on it. As a completely independent organization since February 2004, the foundation has a suitably complex organizational structure and plenty of exciting legal documents that you can read at eclipse.org. Each of the more than 40 foundation members has either direct or indirect representation on the board of directors, along with two representatives from the community of Eclipse committers. Most importantly, all the member companies are following the Eclipse charter by making a commitment to release Eclipse-compatible offerings and to provide continued support for the community of users, researchers, and developers. It is remarkable how quickly Eclipse has grown from a small internal project into the enabling platform for all kinds of areas, such as application development, modeling, programming language research, and so on.
You cannot see where Eclipse ends and a product starts, and this is intentional. The platform itself is written entirely as a set of plug-ins, and the product plug-ins simply join the “soup of swimming plug-ins.” To bring some order to the chaos, the platform does maintain a history of configurations. When a new plug-in is installed, a new configuration is created. To obtain insights into the current configuration of the platform and its update history, consult either Help > About... > Configuration Details or the Update Manager. There you can discover the installed plug-ins that are part of the Eclipse Platform and those that were installed afterward.
Having said that, an Eclipse-based product can exert a certain amount of branding on the appearance of the final application. In particular, a product will usually replace the workbench window icon and splash screen. The product can also configure a set of preferences that will ship as the defaults for users of that product. See Chapter 14 for more details on productizing an Eclipse offering.
The Eclipse Foundation oversees a lot of activity, with contributors numbering in the hundreds. To organize these activities, Eclipse is divided into projects and subprojects. The four main Eclipse projects in June 2004 were:
The Eclipse Project. The three outputs of this project are the Eclipse Platform, Java development tools (JDT) and Plug-in Development Environment (PDE) tools. These three components comprise the Eclipse SDK, a full-featured Java IDE with all the necessary features for building Eclipse plug-ins. The Eclipse SDK is what much of the wider software development community equates with the term Eclipse. This book focuses entirely on the components produced by the Eclipse Project.
The Eclipse Tools Project. Examples of development tools based on Eclipse are tools for visual editing, C/C++ development, UML development, quality assurance (QA), graphical editing, modeling, profiling, and even COBOL.
The Eclipse Technologies Project. Projects in this category are oriented toward research and experimentation into future directions for the platform. These projects are not always intended to become part of products today but instead to explore cutting-edge ideas for future Eclipse-based products. Some of these projects, such as the Equinox project to develop a new Eclipse runtime infrastructure, may migrate into the base platform or other core projects. Topics include aspect-oriented programming, collaborative development environments, Eclipse education, and the Open Services Gateway initiative (OSGi).
The Eclipse Web Tools Platform. This project to develop tools for J2EE is still in its infancy, but has generated a great deal of excitement about its potential to lay the groundwork for high-quality, interoperable development tools for building Web applications.
First check whether your activities can be performed under an existing project. The list of projects is continuously growing, covering a wide range of research topics and product ranges. The Eclipse subprojects are overseen by a project management committee (PMC). If you have compelling reasons to start a new tool or technology, contact the PMC of either the Eclipse Tools Project or the Eclipse Technologies Project.
Having a proof of concept definitely supports your arguments, of course. Furthermore, before you contact the PMC as an individual, it does not hurt to first find other people and Eclipse Foundation members who would like to collaborate with you on the project. If interested in your project, the PMC will guide you through the steps required to establish it as an official Eclipse project.
Each member of the Eclipse Foundation has committed to delivering one or more products based on Eclipse. For example, IBM has moved almost all of its IDE products to the Eclipse Platform. At EclipseCon 2004, many companies showed exciting demos of upcoming products based on Eclipse, including several products based on the new Eclipse RCP.
In April 2004, the following companies had commercial Eclipse-based offerings: Advanced Systems Concepts, Borland Software, CanyonBlue, Catalyst Systems, Codefarm, Embarcadero Technologies, Ensemble Systems, Ericsson, ETRI (Electronics & Telecommunications Research Institute), Flashline, Fujitsu Software, Genuitec, Hewlett-Packard, Hitachi, IBM, INNOOPRACT Informationssysteme, Instantiations, Intel, Logic Library, M7, MERANT, Metanology, Micro Focus, MKS, MontaVista Software, Oracle, Parasoft, QA Systems, QNX Software Systems, Red Hat, SAP, SAS, Scapa Technologies, Serena Software, SilverMark, SlickEdit, SuSE, Sybase, Teamstudio, Telelogic, Tensilica, TimeSys, and Wasabi Systems.
Thousands of projects of various sizes are based on Eclipse. A small number are directly supported by the Eclipse Foundation as official Eclipse projects but a far greater number can be found elsewhere on the Web. Many are hosted at such sites as Source Forge or can be found in the various Eclipse plug-in listings floating around the Web. The following are the best-known portals for finding Eclipse-based plug-ins:
http://eclipse.org/community. Acknowledging the losing battle of trying to track the growing list of Eclipse plug-ins, this page lists other Eclipse information sites that have lists of plug-ins.
http://www.eclipse-plugins.info. This site is probably the longest running Eclipse information portal, best known for its exhaustive catalog of known open source Eclipse plug-ins. If you have a plug-in that you want the world to know about, get it listed here!
http://www.eclipseplugincentral.com. A newcomer to the world of Eclipse portals, this site has an excellent Eclipse news feed and a growing catalog of open source Eclipse-based projects.
Note
FAQ 6 What are Eclipse projects and technologies?
The Eclipse community Web site (http://eclipse.org/community)
Much of the academic research on Eclipse is propelled by the Eclipse Innovation Grants, a financial stimulation project funded by IBM in 2003 and renewed for 2004. The award winners are prominently profiled at the Eclipse community Web site (http://eclipse.org/community).
The Eclipse-oriented research projects have topics that vary widely, such as educational software, modeling tools, program analysis, reverse engineering, aspect-oriented programming, alternative language support, Design Patterns, automated testing, software lifecycle support, groupware techniques, debugging, optimization, and software requirement analysis and specification.
Essentially, all these projects benefit from the strengths of Eclipse: an open source platform that is easily extensible, and very well documented. Using Eclipse gives these research projects a running start and allows them to focus on pushing the envelope in the specific vertical domains they are targeting.
A growing number of universities worldwide are deploying Eclipse as a vehicle for computer science classes. The platform itself can be used very well as an example of state-of-the-art software. Analysis of the Design Patterns adopted in Eclipse could alone easily fill a curriculum for a year. In addition, Eclipse can be used by students to write their own plug-ins. With minimal effort, interesting topics can be explored and impressive results obtained.
Various sources of classroom materials are circulating. International universities that are known to teach courses about Eclipse include, but are not limited to, Carleton University in Ottawa, Ontario, Ecole des Mines de Nantes in France, University of Tuebingen in Germany, Royal Military College of Canada in Kingston, and University of British Columbia in Vancouver.
Owing to the success of using Eclipse in the classroom, the Eclipse Ececis Project was formed in late 2003. Its goals are collaboration and participation in the development and use of open free courseware for Eclipse and related technologies.
This is a monetary grant by IBM to perform innovative research based on the Eclipse Platform. The grant varies from $10,000 to $30,000 based on the scale of the project. For a comprehensive and up-to-date list of award recipients, see the innovation grant Web site.
Note
Eclipse Innovation Grants (http://www.ibm.com/software/info/university/products/eclipse/eig.html)
As with most technologies, Eclipse started out with a single newsgroup. Now, all major, and some smaller, Eclipse projects have their own newsgroups. Some are more active than others. Some have a very specific scope, and others are more broad in their coverage of discussion topics. The Eclipse newsgroup (http://eclipse.org/newsgroups) page has a complete index of the current Eclipse newsgroups and a description of their focus areas.
The most active newsgroup is news://news.eclipse.org/eclipse.platform, with around 1,500 postings per month. Before you post a question to any newsgroup, it makes a lot of sense to search the platform newsgroup for an answer. Chances are that the question has been asked before, and the answer can be found there quickly.
The newsgroups are archived at the Eclipse Web site, and the search engine at the Eclipse Web site (http://eclipse.org/search/search.cgi) can search them quite efficiently.
The Eclipse newsgroups are password-protected to protect them from spam and trolls. Visit http://eclipse.org/newsgroups/index.html and request a free password to access the newsgroups. The same password can be used to browse the Eclipse mailing list archives.
Although Eclipse newsgroups are intended for users and extenders of the platform, the mailing lists are specifically targeted at those who are actively contributing to the development of Eclipse itself. Messages focus mainly on new areas of development, administrative messages about release dates and build information, and general discussions of the subtopic controlled by the mailing list.
The online archive of Eclipse articles contains more than 50 articles written by the Eclipse experts, often the committers of the Eclipse projects described in the articles. When printed in sequence, the online articles contain more than 500 pages of deep knowledge of the Eclipse Platform.
The audience for the online articles is extenders of the platform, so it makes a lot of sense to consult the articles before trying to write your own Standard Widget Toolkit (SWT) widget, implement a preference page, react to workspace resource change events, launch an application from Eclipse, support drag-and-drop, use Draw2D, internationalize your plug-in, turn your plug-in collection into a product, write an editor for your favorite programming language and integrate it into Eclipse, use a tree viewer, use decorators and markers, or create CVS branches in your team project.
In addition to the online Eclipse articles, a wealth of Eclipse experience is reported on the IBM developerWorks® Web site, with many articles and code samples.
In June 2004, books on Eclipse, other than this one, included the following:
Frank Budinsky et al., Eclipse Modeling Framework, Addison-Wesley, 2004 (http://www.aw.com)
Berthold Daum, Eclipse 2 for Java Developers, Wiley, 2003 (http://www.wileyeurope.com)
Berthold Daum, Java-Entwicklung mit Eclipse 2 (German), DPunkt, 2003 (http://www.dpunkt.de)
Berthold Daum, Stefan Franke, and Marcel Tilly, Web-Entwicklung mit Eclipse 3 (German), DPunkt, 2004 (http://www.dpunkt.de)
Eric Clayberg and Dan Rubel, Eclipse: Building Commercial-Quality Plug-Ins, Addison-Wesley, 2004 (http://www.qualityeclipse.com)
Bill Dudney, Eclipse Live, SourceBeat, 2003 (http://www.sourcebeat.com)
David Gallardo, Ed Burnette, and Robert McGovern, Eclipse in Action: A Guide for the Java Developer, Manning, 2003 (http://www.manning.com)
Erich Gamma and Kent Beck, Contributing to Eclipse, Addison-Wesley, 2003 (http://www.aw.com)
Wonjin Heo and Jiwon Jun, Total Eclipse (Korean), Youngjin Publishing, 2003 (http://www.youngjin.com)
Steven Holzner, Eclipse: A Java Developer’s Guide, O’Reilly, 2004 (http://www.oreilly.com)
Junya Ishikawa et al., The Complete Eclipse Guidebook: From Installation to Plug-In Development (Japanese), ASCII, 2003 (http://www.ascii.co.jp)
Shinji Miyamoto, Shinichi IIda, and Yu Aoki, Java Developers Guide to Adopting Eclipse (Japanese), SoftBank Publishing, 2003 (http://www.sbpnet.jp)
William Moore et al., Eclipse Development Using the Graphical Editing Framework and the Eclipse Modeling Framework, IBM RedBooks, 2003 (http://www.redbooks.ibm.com)
Stanford Ng, Stephen Holder, and Matt Scarpino, JFace/SWT in Action, Manning, 2003 (http://www.manning.com)
Steve Northover and Mike Wilson, SWT: The Standard Widget Toolkit, Addison-Wesley, 2004 (http://www.aw.com)
Joe Pluta, Eclipse: Step by Step, MC Press, 2003 (http://www.mc–store.com)
Sherry Shavor et al., The Java Developer’s Guide to Eclipse, Addison-Wesley, 2003 (http://www.aw.com)
Carlos Valcarcel, Eclipse Kick Start, Sams Publishing, 2004 (http://www.samspublishing.com)
Rob Warner and Robert Harris, The Definitive Guide to SWT and JFace, Apress, 2004 (http://www.apress.com)
Seongjun Yun, Sang-Min Cho, and Jeong Il Song, Eclipse: Reinforcing the Java World (Korean), Hybird, 2003 (http://hybird.net)
To manage and track Eclipse bugs and feature requests, the Eclipse Project uses Bugzilla. The main entry point to the Eclipse Bugzilla can be found at https://bugs.eclipse.org.
Do not be shy; post a bug if you see something wrong, even if you are in doubt whether it really is a bug. The committers of the relevant component will quickly decide what to do with your bug report. Also do not think, Someone else will report the bug or at least the Eclipse developers themselves will see something so obvious. Even the obvious things need to be documented and reported to be fixed. Your help is crucial in continuously improving the quality and robustness of the Eclipse Platform.
Before posting a bug, be sure to check whether it has already been posted. You can use the Eclipse Bugzilla search engine. Search instructions can be found at the Bugzilla page under the heading Help With Bug Reporting.
In short, Bugzilla is split up into “products,” representing the major areas of interest in Eclipse: C Development Tools (CDT), Eclipse Modeling Framework (EMF), JDT, and so on. To post a bug on the generic Eclipse infrastructure, choose Platform. Choose the component, such as UI, that you want to provide feedback on, and be sure to follow the bug-writing guidelines mentioned on the bug report Web site. You will need a password to access Bugzilla. This is mainly for your own protection; the intent is to keep the spammers out.
Writing good bug reports or feature requests is an acquired skill. A great place to learn the basic etiquette is, “How to Ask Questions the Smart Way,” by Eric Raymond and Rick Moen. Note that Eric and Rick are not affiliated with Eclipse, and you should not contact them with your Eclipse questions. Their article is linked from eclipse.org and can be found easily on the Web using your favorite search engine.
Keep in mind that the Eclipse committers are few, and the community is large. Bugzilla tracks thousands of defects and requests, and the committers have limited time to investigate vague, poorly described, or inaccurate reports. Always include the Eclipse build number in your bug report, which can be found in the Help > About dialog.
Note
FAQ 19 How can I search the existing list of bugs in Eclipse?
FAQ 20 What do I do if my feature request is ignored?
Eric S. Raymond and Rick Moen, “How to Ask Questions the Smart Way” (http://www.catb.org/~esr/faqs)
Visit the Eclipse bugs Web site to search for an existing bug report. The Eclipse Project uses Bugzilla for bug reporting and uses it to not only store bug reports but also feature requests, plan items, and architectural discussions. Before posting a bug, see whether it has been posted already. If you find yourself overwhelmed by the Bugzilla query page, you’re not alone. Look for the link at the bottom of the query page, Give me a clue about how to use this form.
Don’t be put off by little or no initial response to a feature request logged in Bugzilla. Sometimes, the committers are focusing on feature deadlines or other priorities, but rest assured that everything logged to Bugzilla is at least read by one or more committers within a week. If your request gets no response, you can do some things to help speed up the process.
First, make sure that your request is well described and motivated. Eclipse Bugzilla gets many feature requests, so you need to “sell” your request to the committers and convince them why your request is important. If you are requesting a feature, demonstrate why it is useful to not only you, but also others. If you are requesting new API, you need to describe your main use cases and describe why they cannot be implemented using existing API. Keep in mind that as stewards of their individual plug-ins, committers have an obligation to prevent feature bloat. API is typically added to a plug-in only if it can be demonstrated to be broadly useful to a large number of downstream consumers of that plug-in. If every little requested feature were added without rigorous scrutiny, every plug-in in the platform today would be at least twice as big and probably much slower in execution.
Once you have convinced the committers that your request is valid, keep in mind that there is no guarantee it will be implemented for you. They still have only limited time and are focused primarily on major features in the development plan. However, at this point, you are welcome to implement the feature yourself and attach a patch of your implementation to the bug report. Committers will then review your patch and either apply it or reject it. If they reject it, they will describe their technical or other reasons and will often work with you to get it into suitable shape for releasing. Don’t forget: In open source, as in much of the world, there is no such thing as a free lunch. The Eclipse committers will implement your feature only if they believe that it is truly useful to the users of their component. If they suspect that you are simply asking them to do your work for you, you’ll be out of luck.
Documentation for Eclipse SDK releases is available in PDF form from eclipse.org. Obtaining PDF documentation for other Eclipse software, or for non-release builds is a bit more involved.
When you download Eclipse code, documentation is provided in the form of HTML files, made accessible through a table of contents contained in a file called toc.xml. The contents of the HTML files can be browsed and searched easily with the Eclipse help system (see Help > Help Contents). The same information can be found online at the Eclipse documentation Web site.
Converting HTML to PDF form is somewhat labor-intensive. Although tools are available, such as HTMLDOC, to automatically convert HTML to PDF, the exact selection of files to include in the PDF and in what order requires some extra work. The best approach is to start with the toc.xml file and either write a conversion script or develop an Eclipse plug-in, as is done in the tocviewer plug-in used to write this book.
Since June 2004, Eclipse downloads come with PDF versions of the documentation. Check this book’s CD–ROM or the Eclipse download site.
Note
HTMLDOC by Easy Software Products (http://www.easysw.com/htmldoc)
eclipse.org documentation page (http://eclipse.org/documentation/main.html)
eclipse.org downloads page (http://eclipse.org/downloads)
At least three simple ways exist to find documentation for extension points:
Use platform help. See Help > Help Contents > Platform Plug-in Developer Guide > Reference > Extension Point Reference
Go online to the Eclipse Project documentation site
While contributing an extension point using the PDE Manifest Editor, select the Extensions tab and choose Add > Add... > Generic Wizards > Schema-based Extensions > Details
Note that Search > Plug-in Search lets you search for all uses of a given extension point.
The answer to this question depends on what aspect of Eclipse you are talking about. Everything you see on eclipse.org is governed by the Eclipse Web site terms of use (eclipse.org/legal). This document describes what licenses apply to the content, along with other legal information such as export control information. Everything you contribute through the Web site, including the Eclipse mailing lists, newsgroups, and CVS repositories, is governed by these terms of use.
Any software you download from eclipse.org is governed by a similar user agreement. This document, contained in a file called notice.html in the eclipse install directory, describes the licenses and other legal information that applies to the software. Each Eclipse plug-in typically has additional legal information in a file called about.html.
Unless otherwise noted in the Web site terms of use and software user agreement, most Eclipse content is licensed under the Common Public License (CPL). The CPL is approved by the Open Source Initiative (OSI). The OSI is a non profit corporation dedicated to managing and promoting the Open Source Definition for the good of the community, specifically through the OSI Certified Open Source Software certification mark and program. Approval by the OSI bestows confidence on a license that it really is “open source.” The OSI also makes copies of approved open source licenses available on their Web site. The Eclipse Public License (EPL) is a new license, very similar to the CPL, that was introduced when the Eclipse Foundation was created. The EPL is currently undergoing OSI certification, and will eventually replace the CPL for any new content contributed to the Eclipse Foundation.
You should always speak with a lawyer for complete interpretation of any license, but it is safe to say that in essence the CPL provides free, unrestricted access to the source code and other creative matter it covers. CPL-licensed code can be redistributed or sold without making royalty payments to the copyright holders. The fact that dozens of companies are shipping commercial Eclipse-based products is a strong indication that the CPL is widely regarded as a safe, liberal open source license.
Note
CPL FAQ (http://ibm.com/developerworks/library/os–cplfaq.html)
CPL version 1.0 (http://www.opensource.org/licenses/cpl.php)
eclipse.org Legal FAQs (http://eclipse.org/legal)