A Retrospective of the Last Twelve Months with Indigo
My Indigo Year: A Review
In my 'The Helios Year in Retrospect' article for last year's Java Tech Journal (Issue #1 on Eclipse Helios), I concluded that the new Java owner, Oracle, should create a reliable release schedule like the one commonly used at Eclipse. But things turned out differently: according to current plans, Java 7 will be completed just after the Indigo release, in late July. While NetBeans 7.0 and IntelliJ IDEA 10.5 have already achieved Java 7 support, the most popular Java IDE hasn't shipped with Java 7.0 support, with the current version 3.7. Was sticking to the set release date the right thing to do, or would it have been wiser to make an exception, and pay attention to the saying "it's done when it's done"?
Many companies and open source projects act according to this motto. The best known example is the first-person shooter "Duke Nukem Forever": announced in 1997, the release was moved back countless times. The game has now been available since the 10th of June, twelve days before Indigo was released. What would have happened if Indigo had not been delivered until all of the originally planned functions were complete, instead of trying to develop the maximum number of features in the time available, and sticking to the fixed delivery date in mid/late June, like in previous years? While Eclipse could advertise itself as having "Full Java 7 support," all the other new features of the Java IDE and many other projects would have had to wait.
Together with the Eclipse platform, Java Development Tools (JDT) is still Eclipse's flagship project, but it's just one ship of many. This move would have been especially unwelcome for those who won't use Java 7 in the near future. It also would have been a disadvantage for Eclipse-based products and projects, as their schedules would have become confused. Luckily, Indigo resisted the temptation and their eighth Siimultaneous Release (if Eclipse 3.0 and 3.1 are taken into account) was shipped on schedule, on 22nd June.
On the Indigo website 62 projects, or project teams, are listed as being involved in the release. In comparison, last year´s Helios release contained 39. Take a closer look and you´ll see that the way of counting has changed. Some sub-projects are now counted that have previously not been counted individually, but were considered as part of their parent project. Irrespective of the method of counting, there are two more projects in Indigo than in Helios: eleven projects joined, and nine left. This is, in terms of percentages, is the lowest growth of all the Simultaneous Releases (Fig. 1).
Whether this means that Indigo has already reached the saturation point, or whether this is just a temporary effect of the financial crisis and the subsequent reduction of the open source commitment of many companies, only time will tell. 408 of approximately 1,000 Eclipse committers (that's 24 less than the Helios committers), who are the only ones allowed to change the source code, created Indigo. Indirectly, some 50 companies were involved, as these were where the 408 committers were recruited from. This does not include the numerous contributions that were submitted through the bug tracking system, which found their way through the committers, and into the code.
Unfortunately, the Test and Performance Tools Platform Project (TPTP) is no longer on board. TPTP was, together with C/C++ Development Tooling (CDT) and the Java IDE, one of the three very first projects in the Eclipse Simultaneous Release in 28th June, 2004. In the absence of a name, the second release was named after the Eclipse IDE version. That was 3.0, the first version, based on OSGi. Since February 2010, TPTP is now history; the development was stopped and the project has been archived. The Runtime Analysis Tools (RAT) is now set to be its successor. In March, the existing Eclipse project was made possible thanks to a donation from Google, who had come to possess the Java Profiler CodePro through the acquisition of the U.S. company Instantiations. RAT, which helps to locate where most time is wasted, is complemented by MAT, the Memory Analyzer, which is in its third year, and evaluates the Java heap to track down memory leaks and to optimize memory consumption. Another tool that fits would be JaCoCo, a project unfortunately not (yet) part of Eclipse, from the makers of the test coverage report plug-ins EclEmma. The new, developed-from-scratch EclEmm replacement is based on the technology recording run-time data; the so-called instrumentalization of Java classes. The other projects that are absent in Indigo weren't a flash in the pan either, and had been with Eclipse for at least two years, since Galileo. The top-level project Device Software Development Platform (DSDP) was dissolved: the project's target management can be found partly in CDT; the rest was formed into an independent project, just like Sequoyah, which is aimed at mobile devices with the Tools for Mobile Linux and Mobile Tools for Java. The other seven projects are still in their original forms; they just don´t take part in the Simultaneous Release. Their health can be judged, among other things, by looking at the number of code changes in the last few months. EMF Teneo (a connection of the Eclipse Modeling Framework to relational databases) and GMF tooling (the only one of four sub-projects of the Graphical Modeling Framework project, which is not at Indigo) look quite healthy. In the Java Emitter Templates (JET) project, which generates code and other text from an EMF model, there are only a few changes. But, because JET is mature and there are a number of alternatives, you have nothing to fear. Also vital, but increasingly exposed to internal competition, is Buckminster. In particular, Tycho which is based on Maven and which has been an Eclipse project since August 2010 is becoming more popular in plug-in building than it. The two SOA projects Swordfish (an extensible SOA Framework) and BPMN Modeler (an editor for so-called business-process modeling notation diagrams,) as well as Mint (JDT extension for model-driven software development) are not looking good, and it's likely they will be archived soon.
Considering the size and range of projects, the growth of Indigo is bigger than the addition of two new projects suggests. Also encouraging is that some projects that have not been with Eclipse very long, have found their way into Indigo. One of the more major projects which migrated is Object Teams, a language extension for Java. Similar to aspect-oriented programming, Object Teams adds object orientation in order to get to grips with complexity. Refreshingly different and closer to the real world, various aspects are implemented through roles and teams on a higher level of abstraction. Object Teams is based on JDT, and it will provide the necessary tools for editing source code and generating executable bytecode directly. Object Teams was created in collaboration with the Fraunhofer Institute for Computer Architecture and Software Technology, and the University of Berlin. Since January 2010, it has been an Eclipse project, and because during incubation the version number may not be larger than 1.0, the version number 0.7 in Eclipse followed an external release of version 1.4. A few milestones of version 0.8 followed, and finally came the great leap in Indigo, to version 2.0. WindowBuilder which can be used to graphically edit surfaces is similar to CodePro: it's also a donation by Google, which goes back to the purchase of Instantiations (Fig. 2). And there's another parallel: just as CodePro (alias Runtime Analysis tools) now fills the gap left by TPTP, the better equipped WindowBuilder suppresses the Visual Editor. For the Visual Editor, the last Simultaneous Release came after several partially successful attempts to revive it in June of this year (Visual Editor was one of seven projects to take part in the second Simultaneous Release in 2005, and in 2006 it was one of the ten Callisto projects). In contrast to NetBeans' Swing GUI Builder, also known as Matisse, WindowBuilder and Visual Editor operate directly on the source code: changes can be performed in the code, and existing code can later be edited graphically, if the code is not too complicated. Its commercial past explains why this project is supported in addition to SWT Swing. Support for the Google Web Toolkit (GWT) - which is probably one reason for the takeover – will be continued outside of Eclipse by Google itself, as GWT Designer.
Also fairly new to Eclipse and anything but a lightweight is Jubula, a project for creating and running automated tests of graphical user interfaces. Jubula was introduced to Eclipse by the German BREDEX company, and earlier sold as GUIdancer. Therefore, it is not surprising that, just like WindowBuilder, not only is SWT supported, but Swing and Web applications are also supported. Jubula is aimed not at software developers but at test engineers, unlike SWTBot, a Java framework for surface testing. The new download package "Eclipse for Testers" is also aimed at them.
With four new projects in the main project Eclipse Modeling Framework (EMF) it is difficult to keep track. The Agent Modeling Platform (AMP) provides tools primarily for scientific research, for example swarm behaviour or epidemics. The behaviour of an individual agent is modelled as a funcTion of adjacent agents, in order to simulate a variety of such agents in a system and display the results, both graphically and in other formats (Fig. 3). AMP and the Eclipse project generation Factories (EGF) have the 22th of April 2009 in common: this is the day on which the project proposals were approved. While AMP only uses EMF for its own needs, EGF extends EMF to improve the tooling for orchestrating the generation of large, complex and customizable models. EMF Facet starts working after the generation. Facet extends existing models without changing them, similar to aspect-oriented programming, which extends object-oriented programming. This is to ensure that independently developed extensions add more facets to a model, without interfering with each other.
The fourth EMF Project, and Indigo newcomer, is Graphiti, which is located in the new sub-project Graphical Modeling Project (GMP). Using Graphiti, one can create graphical editors, not only for EMF models without much knowledge of Draw2d and the Graphical Editing Framework (GEF). Even a version for Flash is being considered.
Scout has nothing at all to do with EMF. Scout was developed by the Swiss company, BSI AG, and in Eclipse it now co-exists with Riena as a platform for business applications. According to the company, Scout is used by more than 30 customers. The client exists as a SWT and Swing version, and a Web interface is planned. The development of Gyrex is driven solely by the German company AGETO, by Gunnar Wagenknecht, who is not unknown at Eclipse. Gyrex was originally Cloud-free, but was renamed in early 2009 to avoid associations with cloud computing. Gyrex is a server-side Equinox, to connect multiple servers to form a cluster, not to be confused with Virgo, the Enterprise Java Web Application Server that is not a part of Indigo. Unfortunately, M2E : ("m" stands for Maven, "2" for "to", because it brings the build system for "e" Eclipse: it integrates Maven into Eclipse) is only a one-company project. It contains an editor for pom.xml files and the integration of Maven repositories. The company is none other than the inventor of Maven Sonatype, from the USA.
The growth of sub-projects by WTP and Mylyn, together with projects such as ObjectTeams, WindowBuilder, Jubula and Scout, which were already mature when they joined Eclipse and Indigo, all explains the enormous increase in the amount of code. But this amount of code needs to be maintained. I especially like the fact that Indigo gained support in the core competencies of Eclipse, the support for Java development – not only for SWT, but increasingly also for Swing and the web.
- Key Data
- Noteworthy Changes