The Eclipse framework has now become an integral part not only of thedesktop developers' consciousness but that of embedded developers aswell. Why has Eclipse takenoff in both very different worlds? The primary reason for this is theextensibility and adaptability of the Eclipse framework to a veritablehost of applications. Remarkably, this is a far cry from its originalIBM roots as a Java-based development environment for WebSphereapplications.
The Eclipse framework isnot a single entity. It is built up from many smaller pieces allworking together called plugins to provide not only an integratedenvironment but one that is highly modifiable and extensible. Thisextensibility is accomplished not only via connection or interactionwith existing add-on plugins but in the ability for just about anyonewith a modicum of development experience to add their own plugins in arelatively short amount of time.
Gone are the days when an IntegratedDevelopment Environment (IDE) vendor would need a largegroup ofdevelopers just to design and code the numerous windows, buttons andwidgets necessary to field a professional IDE. Eclipse forms thegraphical backbone for these IDEs across a wide variety of desktopoperating systems freeing up a vendors programmers to work on the corecompetencies of the company rather than just the vehicle for userdisplay and interaction.
In its earliest literature Eclipse billed itself as “An IDE foreverything and nothing”. Eclipse's mission is now defined as “Eclipseis an open source community whose projects are focused on providing anextensible development platform and application frameworks for buildingsoftware”. Coming as it did in the very beginning of the Web-baseddevelopment approach to open source software, Eclipse is heavilydependent on such new online capabilities as Wiki thru its Eclipsepedia.
|This article is excerpted from a paper ofthe same name presented atthe Embedded Systems Conference Boston 2006. Used with permission ofthe Embedded Systems Conference. For more information, please visit www.embedded.com/esc/boston/|
An EPIC event for Eclipse
A fairly new addition to the ranks was originally started by Genuitec,Innopractand Instantiations. called Eclipse Plugin Central or EPIC. EPICwas recently formalized and accepted by the Eclipse Foundation. EPICis defined as offering “the Eclipse community aconvenient, information-rich portal that helps software developers findopen source and commercial Eclipse plugins, tools, and products thatenhance the entire Java software development life-cycle.”
<>A License to Bill
Eclipse is governed by the EclipsePublic License or EPL . This is distinct and quite different fromthe more widely known GNU PublicLicense or GPL . TheEPL is unique in that while it includesprovisions for modifiers of the core Eclipse framework or existingEclipse plugins to provide bug fixes, improvements and modificationsback to the community, it does not preclude the creation of proprietaryplugins and features that can be sold by vendors.
In the parlance of the open source community the EPL is notconsidered viral i.e. it doesn't of and by itself “infect” other piecesof software forcing plugins (and their vendor companies) to becompletely open. Vendors are free to make their own decisions aboutwhether or not to make their product source code openly available totheir customers.
There seems to be three mindsets when it comes to consideringEclipse as an underlying framework for any desktop application, notjust embedded operating system IDEs. The first mindset is the mostexclusionary; to ignore or otherwise refuse to utilize Eclipse in anyway in an IDE or application project. This occurs most often in vendorswho have a fairly complete proprietary system that has already been inuse for quite some time.
This represents a fairly large monetary investment for thesecompanies so they are naturally reluctant to hand over the reins ofcertain product areas to an open environment such as Eclipse. Theproblem with this approach is that it does not typically allow the userto mix-and-match best-of-class tools from other vendors in a singleenvironment instead locking the user into a fairly exclusionaryproprietary approach.
The far more dominant approach to using Eclipse is that ofproprietary vendors who use Eclipse as their graphical desktopbackbone, in a sense piggy-backing on top of an open environment(Eclipse) to provide their own still-proprietary functionality. Oftenvendors with this mindset will reduce or otherwise modify the Eclipseenvironment thereby replacing certain Eclipse functionality with theirown proprietary solutions for specific types of application usage ordevelopment.
In this case, the vendor is free to utilize the Eclipse frameworkand its open nature while reserving the most critical pathfunctionality for a proprietary solution. In some extreme cases howeverwhat is left may not resemble the core of Eclipse as much as theircustomers might wish it to.
A still smaller group of companies, usually with a much smallerlevel of engineering investment, will endeavor to retain all or most ofthe same open source philosophy employed by the Eclipse Foundation.These companies usually ship their products as complete source code orsource-code-plus-binary solutions.
The advantage to this approach is two-fold. First these vendors willusually have a smaller customer support workload as the customersthemselves can often address bugs or create workarounds withoutrequiring outside assistance from the vendor. Customers with thisability also may develop an increased sense of ownership in the productand a willingness to contribute to its continued success.
Secondly, these smaller vendors often enjoy a healthy level ofprofessional services work in designing and delivering modificationsnot only to their own core product lines but often to the Eclipseframework as well. All of these add up to a greater level of customerinteraction and control of the application or development environmentwhile ensuring a steady stream of product improvements and enhancementsto the vendor.
Eating Your Own Dog Food
In the software development industry, there is a saying among IDEdevelopers called “Eating Your Own Dog Food”. This refers to the factthat many developers of IDEs don't actually use their IDEs either todevelop their IDE product or as a development environment for otherproducts. Instead many IDE developers use command-line methods toconstruct the interface they expect users to use. As a result, sincethe developers of the IDE are not, in fact, users of the IDE, there isa loss of understanding or empathy for the user experience. They don'teat their own dog food.
If a developer was forced to eat something (like dog food) that hecould design then the dog food would almost by definition be the besttasting dog food around. What does this have to do with Eclipse?Eclipse eats its own dog food. To develop plugins to run in Eclipse,you use Eclipse and its PluginDevelopment Environment (PDE) plugins.
Within the PDE the developer can create a new plugin and can thenrun and debug it from within Eclipse using what is called the RuntimeWorkspace. The Runtime Workspace is a directory just like the regularWorkspace directory that is persistent and works as if it was a realWorkspace for the plugin under test. When testing, Eclipse actuallylaunches a second version of itself that acts as if it was a regularEclipse installation with the new plugin already installed. Developerssee and do exactly what the user would see and do.
Armed with the PDE, plugin developers can develop for Eclipse whileworking in Eclipse. This means that literally every Eclipse developeris also a user with a user's perspective of the environment. In thisway, the Eclipse community stays fully in touch with its users with anaccompanying willingness (and self-interest) not only to test newfunctionality but to participate in bug fixes and updates. The PDE isconstantly under revision to accommodate the needs of an ever-wideninggroup of Java developers working in both the desktop application andembedded spaces.
To further extend the development environment, Sample Projects,Project Managers and Wizards (seeFigure 1, below ) were created to allow for fast and easy initialdevelopment of plugins. Indeed, in a matter of minutes a developer canmock up a complete plugin solution, test it and deploy it to its .jarfile. In this way, the act of creation of a plugin in and of itselfresolves a host of deployment issues before any new code is evenwritten.
|Figure1: Plugin Wizard|
The need for a higher level deployment mechanism than simply pluginswas also needed. What if a single vendor wanted to ship more than oneplugin and didn't want to go through the process of extracting eachplugin to its own deliverable and then deploying an entire group ofthem? Developers needed a simpler mechanism for developing anddeploying a multiple-plugin solution.
Eclipse Features were created to address this need. Eclipse Featureshave their own manifest file called feature.xml and this file definesthe entire set of plugins to be fielded as part of that Feature.Vendors could now deploy the Feature with its underlying plugins ratherthan each plugin separately. In addition, Features allow for a betterbranding strategy whereby a vendor can supply more fields such asopening banners and vendor-specific information that was difficult toencapsulate at the plugin level.
Also as an outgrowth of all the discussion of larger levels ofproduct deployment and along with a growing need for live or web-basedmethods for upgrading products after deployment in the field, the ideaarose to create an online method of updating or uploading the latestrevisions of a product to the installed customer base. Even the Eclipseenvironment itself would benefit from a solution to this problem as nowusers would not have to download new updates and then port all theirdevelopment work from one version of Eclipse to the next. The solutionfor this problem is known as Update Sites.
With Update Sites, Eclipse users can connect to and download newrevisions of Eclipse and most if not all of the most recent add-onplugins directly from a Web-based interface. This was not just adownload method but a way for dynamically updating the environmentwithout affecting current development work. With a few clicks, a usercan now virtually guarantee that they are using the most recent Eclipseplugins and development environment available.
What About C?
One of the key points in the evolution of Eclipse that was of criticalimportance to embedded development was the development of the C/C++Development Toolsuite or CDT .The CDT was originally designed and developed by QNX as a completedevelopment environment for C and C++ developers utilizing the GNUdevelopment tools.
With the addition of the CDT, developers could now develop and debugnot just standalone Java applications or Eclipse plugins in Java butactual local and embedded C and C++ code. As the GNU cross-compilertools and binary utilities are very familiar to users of many IDEs andReal-Time Operating Systems, this made Eclipse a compelling solutionfor embedded development.
The C/C++ perspective provided by the CDT plugins updated both theEclipse Project Managers and the Eclipse Debug Perspectives toaccommodate local and remote debugging of code via GDB and the GDBServer in addition to the existing Java functionality. Now the Eclipseframework could be used with 3 languages.
It was therefore just a matter of time before additional interfacesfor languages like COBOL, FORTRAN and Ada among others would also beprovided by vendors. Now the embedded industry in particular is seeingmany of the “old guard” companies who used to provide a completelyproprietary IDE now providing Eclipse-based solutions of one sort oranother. Many of these vendors are now bringing brand new approachesand brand new operating systems to the new Eclipse model.
Viewing the Eclipse
The Eclipse framework has gone through many changes in a very shortamount of time. New plugins are being added all the time and theEclipse framework has graduated to the status of an ecosystem whereopen source members, commercial vendors, and users all communicate tobetter the environment and to add an ever increasing level offunctionality.
|Figure2: Callisto Update List|
In an effort to increase the overall amount of capability provide byEclipse, an ambitious new project is coming to fruition known as Callisto (Figure 2 above ). Callisto is part ofthe Eclipse 3.2 release but it entails more than just a new release ofthe core Eclipse environment.
Callisto is also a synchronization point for several distinctEclipse projects including the CDT, the Business Intelligence and Reporting Tool(BIRT) , Graphical EditingFramework (GEF) and several others. A complete list can befoundon the specific web pages.
In addition to Callisto, even newer capabilities are being added forDevice Software Optimization (DSO) ,Remote Target Management and Rich Client Platforms (RCP) among averitable host of others.
Not only is the Eclipse framework here to stay, but an ever wideningcircle of development problems are being addressed by it. It is fastbecoming a defacto standard for development environments of many kindsacross a multitude of industries including the embedded space.
Mike McCulloughis Director, Professional Services at Embedded Planet,a provider of hardware and software to the embeddedindustry. He has published several articles on Eclipse plug-indevelopment and Linux board support package development.
Other Eclipse resources onEmbedded.com:
1) Embeddeddesign needs open IDEs
2) Eclipse concepts yield reliable software
3) TuningEclipse CDT for remote debug
4) Choosinga standard for IDEs
5) Eclipseplatform eases SoC development
6) Extensibleplatform integrates tools
7) Eclipse: Under The hood
8) TheEclipse Device Software Development Platform: Device Debug
9) TheEclipse Device Software Development Platform: Target Management