A Retrospective of the Last Twelve Months with Indigo
My Indigo Year: A Review - Part 2
In addition to the eleven new projects, the other 28 – or 51, depending on how you count the Indigo projects – have been improved as well. For example, the Marketplace Client, where the installation of plug-ins has been made even easier. If you've found something on the web and the plug-in vendor offers a special text link or a specially linked image, you can just drag and drop it onto the title bar of the currently running Eclipse application, whereupon the Marketplace dialog will open, and the installation only needs to be approved, to install the plug-in (Fig. 5).
Since it is not working with the update site link, now only the plug-in vendors can add this special link to their websites. Since the Marketplace is established as a catalog of plug-ins and services, and since most installations are done and recorded by it (on 20th May, the 500 000th installation was counted) Marketplace provides us with a lot of exciting numbers. For example, the ranking of the number of installations in the version control systems shows "SVN ahead of Git, ahead of Mercurial" in the code analysis tools "FindBugs ahead of EclEmma, ahead of Checkstyle".
Even if SVN is still ahead, distributed version control systems, and in particular Git, play an increasingly important role. The switch to Git does require some rethinking on the part of long-term CVS/SVN users, but rewards them with high speed and with merging that is simpler than they ever thought possible. As those with an eagle eye will have observed, EGit is certainly a highlight of Indigo. The Eclipse Git support has matured to version 1.0 in Indigo, and is ready for production use (Fig. 6). Also, for some time now NetBeans 7.0 and IntelliJ IDEA have offered Git support. IDEA, however, requires the installation of the command line version of Git for the specific operating system; and NetBeans, who advertise it in their 7.0 video, employ shamelessly, but legally, JGit, the Java implementation of Git. These, and other use options, are allowed by the strict separation in JGit, without depending on Eclipse and EGit, the Eclipse integration.
Xtext has made the jump from 1.0 to 2.0 and brings the first refactoring feature in the form of the renaming of identifiers. The version of CDT  jumped from 7.0 to 8.0, and with Codan it offers improved static code analysis. The version number of the PHP Development Tools (PDT) reached 3.0, just like the version number of the Dynamic Language Toolkit (DLTK), which is based on PDT. Unfortunately, there is no longer a download package available from Eclipse for PHP developers. Due to incompatible licenses, it was decided to offer packages with the debugger as an external download.
Often, it's the little things that make life pleasant. For example, in the JDT debugger a dialog now prevents the accidental deletion of conditional breakpoints. That's already happened to me several times, because I like to use the conditional breakpoints for debugging or tracing purposes, by using System.out.println () in the condition. Another new feature is the ability to reuse a condition of a previous input, making it easy to move or restore. The help system suits my bumbling, now that a set Scope is displayed directly above the search results. Previously, the Scope was easy to miss, and you wondered about too few hits. For those who are interested in even more highlights of Indigo, the Indigo series of articles on JAXenter and the traditional top-ten countdown by Ian Bull is recommended.
In addition to Indigo
Only about a quarter of all Eclipse projects made the effort to meet the requirements of the Simultaneous Release. The total number of Eclipse projects has increased by nine projects, which corresponds to the proportional growth of the Helios / Indigo projects. There are 23 new projects, and 14 terminated projects, some of which have been mentioned already. To list all the new and terminated projects would spoil this paper. If you wish to know more, you should keep an eye on the new project proposals, and the creation or termination reviews at the project overview page and on the side of the recent reviews.
Code Recommenders, one of these 23 new projects has, in my opinion, the potential to be the next Mylyn. Like Mylyn, Code Recommenders helps the developer to focus on the essentials, by highlighting certain things and hiding others. This information is gathered by Mylyn, from observing which files are opened and which areas are edited. So, what's new in Indigo? When a new task is started, the information from a possibly existing Java stack trace can be obtained. Code Recommenders analyses how a given framework is used, for example, whether methods are often, rarely or never used. The most commonly used methods appear in a list above for code completion (Fig. 7). I once had a button that could be operated with the mouse, but not with the keyboard. As it turned out, the author had registered, by mistake or ignorance, a wrong listener. Using Code Recommenders that would not have happened.
Eclipse Labs, which launched in May 2010 and was largely advocated for the not-yet-Eclipse projects, has hardly been heard of. The five most active Labs projects are listed at the very bottom right-hand corner on Eclipse.org, but that's all. Eclipse is quite keen on Git, and since Eclipse Labs does not support Git, it is not in the picture. But, perhaps it has only has been waiting for JGit 1.0. Eclipse has also been silent about e4, the next Eclipse platform; even though Eclipse Platform 4.1 brings many new and exciting technologies, such as Dependency Injection. The nice thing is that it is not really a new platform, but a collection of several independent technologies that can be used separately and in combination with Eclipse 3.x.
What else happened
The Indigo year got off to a bumpy start. Shortly after the release of Helios, in the Java 6 update 21, Oracle replaced the manufacturer name "Sun" with its own. This small, inconspicuous change caused Eclipse in Windows to sporadically crash, because the launcher using the manufacturer's declaration no longer recognized the Hotspot VM, and did not increase the PermGen memory space, as is necessary for the stable operation of Eclipse. Three weeks later, Oracle updated the undo, and solved the problem. In August, Oracle dropped a bombshell and sued Google for alleged patent infringement by Android. Whether justified, or a move made out of greed, it was also hotly debated in the Eclipse community.
Nevertheless, more than 90 percent of the developers of Hudson, a popular continuous integration server, voted in favour of a move to GitHub under the new name Jenkins. The story took a bizarre turn when a little later, in February, the original Hudson project also moved to GitHub, and then, in May, Oracle transferred Hudson to Eclipse. Many of the Eclipse community sympathized with Jenkins and wanted the proposal to be rejected. But, even if Hudson is still not a true Eclipse project, there are only formal hurdles in the way now. In an oddly parallel move, Oracle donated its open source office package, OpenOffice.org to the Apache Foundation. Oracle's open source support is commendable, even if it was reduced in certain areas, but an improved communication with the community would be desirable – especially before making decisions.
Not only outside, but also within the Foundation, sometimes debates flare up. Following discussions on the use of the Friends of Eclipse program to attract donations in May, the Hudson project proposal once again sparked a fundamental debate over the interplay between industry and individuals, through licenses in general and the (supposed) requirements made by the Eclipse development process. A key element of the Eclipse development process is to ensure Intellectual Property (IP), thus the Foundation requires that all code conforms to the Eclipse license, and that no intellectual property is violated. Eclipse Bugzilla is currently serving as a control gate, through which each code contributed from outside - and therefore not written by Eclipse committers themselves - must travel. A contribution will be added as a patch to a Bugzilla entry, which is only possible after prior authentication, whereby the contributor agrees to the use of their contributions under the Eclipse license. Distributed systems such as Git version offer more convenient options than using a patch, when it comes to accepting proposed changes - especially if you wish to change a code base that has been further developed. This is one of the challenges that affects the Eclipse process, and is one of the reasons for ongoing adjustments at Eclipse.
Slimming did not just take place at the process level, but also with regard to staff. For four and a half years, Lynn Gayowski was the friendly face of the Foundation. Lynn was also behind a number of jokes, for example imitating the dance style of the Eclipse Europa Representative Ralph Müller in a YouTube Video in a response to a video recording of the Eclipse Summit Europe. The gap that resulted from her move to Klocwork in February, was unfortunately not filled, probably because, due to the financial crisis, funding at Eclipse is in short supply (in 2011, the revenue is expected to be under four million dollars; the lowest of the last five years). Therefore, there are only two admins that must keep the increasingly complex computing infrastructure alive. In the weeks before the release, they underwent hard test cases by failure of devices.
As an extension to the Eclipse development process, there is an initiative, which has previously received little attention: planned long- term support which should ensure care and maintenance beyond the two service releases. I personally would rather see these resources be invested in development, rather than in the preservation of the obsolete. If you do not use any internal interfaces in a framework, then it does not rely on an outdated version – and it can easily and safely be replaced by the current version. Even after eight years since Eclipse 3.0 was developed and programmed, plug-ins still run, for example, on 3.7. If you have concerns about the continued existence of a project, you can avoid this through active participation. More information regarding the long- term support is unlikely to be announced before the appropriate workshop on 11th July.
It's quite possible that, with the first of the two Indigo service releases due this September and in February of next year, beside bug fixes, Java 7 support will also be included. The only thing that will change is that the annoying download and compiling of the existing, but not yet released JDT plug-in, will be eliminated. Actually, not many developers will really be using Java 7 straight away. Experience shows that adoption takes quite a while. A year passes quickly, and Juno will be released in June 2012. Unlike Java, Eclipse users move to current versions much more quickly. In combination with the annual, frequent releases, the wait for an innovation to arrive at the customer – the so-called Time to Market – is much shorter than in Java. Not just for Java, but for all the applications and frameworks I use, I would like to see a dependable release schedule, following the example of Eclipse. The Java one should additionally be coordinated with the Simultaneous Release of Eclipse. But I've already requested that last time and then things turned out differently.
- Key Data
- Noteworthy Changes