My last few blog posts discuss a presentation that I regularly deliver titled “What is Eclipse?“. As previously discussed, I tend to introduce people to Eclipse by starting with what they already know: Eclipse is a movie about vampires that I have no intention of watching. Eclipse is a Java IDE. And, as I’ve stated previously, a darned good one. From there, I try to expand the horizon of the listener by introducing the notion of Eclipse as a IDE platform.
To reinforce the notion of Eclipse as a platform, I then generalize beyond the notion of an IDE and introduce Eclipse as a Tools Platform.
I think it’s pretty common knowledge that the original work on Eclipse was done by particularly smart group at IBM (yes, I’m fawning). What’s not common knowledge is that IBM didn’t initiate work on Eclipse to create yet another Java IDE. Eclipse was created to solve a problem. A big problem.
In the mid- to late-nineties, a lot of very powerful tools became available: we had some pretty fantastic tools for doing Smalltalk work; we had great tools for doing Java development; we had great pretty good tools for doing web development; we had great tools for doing database work; and more (there were even a smattering of modeling tools available). The problem was that all of these tools were different. They had different user interfaces. They interacted with different version control and issue tracking systems. You couldn’t keep all your files for one project in one place. It was–despite all the power–a huge mess.
Eclipse was created to be a powerful integration platform that could bring all the tools into alignment. Just the ability to have all your code, property files, documents, HTML, XML, etc. in once place, managed by a single version control system in a single, consistent manner is immensely powerful. A consistent metaphor for user interaction reduces the training burden, thereby making developers productive across a suite of tools in a short period of time. The Java development tools were, as I’ve heard it, created for two reasons: first, as an example to prove that the Eclipse platform could be used to build a world-class Java IDE; and second, to provide world-class tools for building the Eclipse platform itself.
All of the functionality in Eclipse is delivered as a collection of components, or “plug-ins”. The Java development tools themselves are just a bunch of plug-ins that provide Java development functionality. Those plug-ins can be removed, or augmented with additional plug-ins. I use the term “plug-in” because it’s a term that most people understand. But the truth is that I’ve come to be very uncomfortable with the term: the word “plug-in” implies that there is some monolithic chunk of code that lets you insert a little custom behaviour using a highly-restrictive API. But that’s not the case: all of the functionality in Eclipse is a component (even the base workbench, and the component management system itself are components). All components, including those that come with Eclipse and ones that are added by you or third-parties, have access to the same APIs. It’s like a software utopia (think Tron without the MCP).
So Eclipse has this wonderful modular non-architecture that lets you easily augment behaviour by adding new components into the mix. Today there are literally hundreds–if not thousands–of first-class tools that are part of the loosely-coupled-yet-tightly-integrated wonderfulness of Eclipse. The Business Intelligence and Reporting Tools (BIRT) project provides tools that business analysts (i.e. non-programmer-types) use to build world-class reports with feature-rich charts and more. The Data Tools project provides tools for database administrators. The Web Tools project provides a wealth of tools for web designers, developers, deployers, and testers. The Test and Performance Tools Platform (TPTP) project provides tools for–obviously–test and performance work. Of course, I can’t leave out modeling. Modeling at Eclipse, like Eclipse itself, is relatively hard to define. The Modeling project provides tools, but it also produces runtime frameworks (and how do you categorize metamodels?) It’s probably easiest to, again, start with something people understand: modeling tools, like UML2 Tools, and–of course–The Eclipse Modeling Framework with tools to create, compare, validate, query, and manipulate models.
In short, it’s not all about developers.
The Eclipse Marketplace provides a door to a world of tools that make Eclipse do things that the original designers could not possibly imagined. But there’s more to it. Eclipse is… an Application Framework.
