elijbrei daisia father
Karmen Mcarthun
Implementing software modularity is a notoriously difficult task.Interoperability with a large code base written by a diverse communityis also difficult to manage. At Eclipse, we have managed to succeed onboth counts. In June 2010, the Eclipse Foundation made available itsHelios coordinated release, with over 39 projects and 490 committersfrom over 40 companies working together to build upon thefunctionality of the base platform. What was the originalarchitectural vision for Eclipse? How did it evolve? How does thearchitecture of an application serve to encourage community engagementand growth? Let's go back to the beginning.
On November 7, 2001, an open source project called Eclipse 1.0 wasreleased. At the time, Eclipse was described as "an integrateddevelopment environment (IDE) for anything and nothing inparticular." This description was purposely generic because thearchitectural vision was not just another set of tools, but aframework; a framework that was modular and scalable. Eclipse provideda component-based platform that could serve as the foundation forbuilding tools for developers. This extensible architecture encouragedthe community to build upon a core platform and extend it beyond thelimits of the original vision. Eclipse started as a platform and theEclipse SDK was the proof-of-concept product. The Eclipse SDK allowedthe developers to self-host and use the Eclipse SDK itself to buildnewer versions of Eclipse.
The stereotypical image of an open source developer is that of analtruistic person toiling late into night fixing bugs and implementingfantastic new features to address their own personal interests. Incontrast, if you look back at the early history of the Eclipseproject, some of the initial code that was donated was based onVisualAge for Java, developed by IBM. The first committers who workedon this open source project were employees of an IBM subsidiarycalled Object Technology International (OTI). These committers werepaid to work full time on the open source project, to answer questionson newsgroups, address bugs, and implement new features. A consortiumof interested software vendors was formed to expand this open toolingeffort. The initial members of the Eclipse consortium were Borland,IBM, Merant, QNX Software Systems, Rational Software, RedHat, SuSE,and TogetherSoft.
By investing in this effort, these companies would have the expertiseto ship commercial products based on Eclipse. This is similar toinvestments that corporations make in contributing to the Linux kernelbecause it is in their self-interest to have employees improving theopen source software that underlies their commercial offerings. Inearly 2004, the Eclipse Foundation was formed to manage and expand thegrowing Eclipse community. This not-for-profit foundation was fundedby corporate membership dues and is governed by a board ofdirectors. Today, the diversity of the Eclipse community has expandedto include over 170 member companies and almost 1000 committers.
Originally, people knew "Eclipse" as the SDK only but today it ismuch more. In July 2010, there were 250 diverse projects underdevelopment at eclipse.org. There's tooling to support developing withC/C++, PHP, web services, model driven development, build tooling andmany more. Each of these projects is included in a top-level project(TLP) which is managed by a project management committee (PMC)consisting of senior members of the project nominated for theresponsibility of setting technical direction and release goals. Inthe interests of brevity, the scope of this chapter will be limited tothe evolution of the architecture of the Eclipse SDK withinEclipse1 and RuntimeEquinox2 projects. Since Eclipse haslong history, I'll be focusing on early Eclipse, as well as the 3.0,3.4 and 4.0 releases.
At the beginning of the 21st century, there were many tools forsoftware developers, but few of them worked together. Eclipse soughtto provide an open source platform for the creation of interoperabletools for application developers. This would allowdevelopers to focus on writing new tools, instead ofwriting to code deal with infrastructure issues like interactingwith the filesystem, providing software updates, and connecting tosource code repositories. Eclipse is perhaps most famous for the JavaDevelopment Tools (JDT). The intent was that these exemplary Javadevelopment tools would serve as an example for people interested inproviding tooling for other languages.
Before we delve into the architecture of Eclipse, let's look at whatthe Eclipse SDK looks like to a developer. Upon starting Eclipse andselecting the workbench, you'll be presented with the Javaperspective. A perspective organizes the views and editors that arespecific to the tooling that is currently in use.
Early versions of the Eclipse SDK architecture had three majorelements, which corresponded to three major sub-projects: thePlatform, the JDT (Java Development Tools) and the PDE (Plug-inDevelopment Environment).
The Eclipse platform is written using Java and a Java VM is requiredto run it. It is built from small units of functionality calledplugins. Plugins are the basis of the Eclipse component model. Aplugin is essentially a JAR file with a manifest which describesitself, its dependencies, and how it can be utilized, orextended. This manifest information was initially stored ina plug-in.xml file which resides in the root of the plugindirectory. The Java development tools provided plugins fordeveloping in Java. The Plug-in Development Environment (PDE) providestooling for developing plugins to extend Eclipse. Eclipse pluginsare written in Java but could also contain non-code contributions suchas HTML files for online documentation. Each plugin has its own classloader. Plugins can express dependencies on other plugins by theuse of requires statements in the plugin.xml. Looking at theplugin.xml for the org.eclipse.ui plugin you can see its nameand version specified, as well as the dependencies it needs to importfrom other plugins.
In order to encourage people to build upon the Eclipse platform, thereneeds to be a mechanism to make a contribution to the platform, andfor the platform to accept this contribution. This is achieved throughthe use of extensions and extension points, another element of theEclipse component model. The export identifies the interfaces that youexpect others to use when writing their extensions, which limits theclasses that are available outside your plugin to the ones that areexported. It also provides additional limitations on the resourcesthat are available outside the plugin, as opposed to making allpublic methods or classes available to consumers. Exported pluginsare considered public API. All others are considered privateimplementation details. To write a plugin that would contribute amenu item to the Eclipse toolbar, you can use the actionSetsextension point in the org.eclipse.ui plugin.
When Eclipse is started, the runtime platform scans the manifests ofthe plugins in your install, and builds a plugin registry that isstored in memory. Extension points and the corresponding extensionsare mapped by name. The resulting plugin registry can be referencedfrom the API provided by the Eclipse platform. The registry is cached todisk so that this information can be reloaded the next time Eclipse isrestarted. All plugins are discovered upon startup to populate theregistry but they are not activated (classes loaded) until the code isactually used. This approach is called lazy activation. Theperformance impact of adding additional bundles into your install isreduced by not actually loading the classes associated with theplugins until they are needed. For instance, the plugin thatcontributes to the org.eclipse.ui.actionSet extension point wouldn'tbe activated until the user selected the new menu item in the toolbar.
Once the user selects the new item in the toolbar, the extensionregistry is queried by the plugin implementing the extension point.The plugin supplying the extension instantiates the contribution, andloads the plugin. Once the plugin is activated, the ExampleActionconstructor in our example is run, and then initializes a Workbenchaction delegate. Since the selection in the workbench has changed andthe delegate has been created, the action can change. The messagedialog opens with the message "Hello, Eclipse architecture world".
This extensible architecture was one of the keys to the successfulgrowth of the Eclipse ecosystem. Companies or individuals coulddevelop new plugins, and either release them as open source or sellthem commercially.
One of the most important concepts about Eclipse is thateverything is a plugin. Whether the plugin is included in theEclipse platform, or you write it yourself, plugins are all firstclass components of the assembledapplication. Figure 6.3 shows clusters of relatedfunctionality contributed by plugins in early versions of Eclipse.
The workbench is the most familiar UI element to users of the Eclipseplatform, as it provides the structures that organize how Eclipseappears to the user on the desktop. The workbench consists ofperspectives, views, and editors. Editors are associated with filetypes so the correct editor is launched when a file is opened. Anexample of a view is the "problems" view that indicates errors orwarnings in your Java code. Together, editors and views form aperspective which presents the tooling to the user in an organizedfashion.
The Eclipse workbench is built on the Standard Widget Toolkit (SWT)and JFace, and SWT deserves a bit of exploration. Widget toolkits aregenerally classified as either native or emulated. A native widgettoolkit uses operating system calls to build user interface componentssuch as lists and push buttons. Interaction with components ishandled by the operating system. An emulated widget toolkit implementscomponents outside of the operating system, handling mouse andkeyboard, drawing, focus and other widget functionality itself, ratherthan deferring to the operating system. Both designs have differentstrengths and weaknesses.
c01484d022