|
Life On The Bleeding Edge
Those of you that have been visiting EclipseZone these past few weeks may have noticed that about once a week I have posted a front-page story distinguished with the prefix 'Bleeding Edge'. Whether the discussion is about new key binding preference pages, null reference analysis support, or Java 6 compiler support these bleeding edge discussions are typically geared towards brand new Eclipse features that are 'hot off the presses', so to speak. To get to these features, you have to be brave enough (or crazy enough) to download and run one of the ever-so-cryptically-named integration builds (such as 'I20060208-0848') from the Eclipse download site; often times relegating yourself to just a few of the many mirrors, as not all of them propagate these frequent snapshots.
Integration builds are a cornerstone to the success of the broad, de-coupled development that happens on Eclipse. Teams work in isolated environments, relying on stabilized components from other teams as foundations for their domain. Integration builds are a chance for multiple teams to coordinate the publishing of cross-component features and have them available for smoke testing by the Eclipse developers themselves, as well as us, the community.
It may seem crazy to risk the wellness of your workspace on such a daring activity, but the reality is, these journeys down the rabbit hole can provide several benefits:
- Get New Features Sooner - Let's face it, part of the fun of being on the 'bleeding edge' is getting to play with the new toys fresh from the factory. You get to see the new and noteworthy features before they are new and noteworthy.
- Gain Familiarity With Eclipse - Exploring new features regularly means that you also learn about the new little tweaks and tools as soon as they become available, rather than having to mine through droves of new documentation at release-time. This makes you much more familiar with Eclipse in general, and often allows you to uncover existing features you never knew about.
- Feedback, Feedback, Feedback - Perhaps the largest benefit comes from the participation it provides as an Eclipse community member. If you start playing with a new feature (such as the null reference analysis), and you find out that it does something that impedes your productivity, you have an opportunity to chime in and give your feedback before it's too late to make critical, breaking changes. In addition, community members typically use a lot of open source and community-fostered plug-ins - it may be that some new feature or code change has broken one of these plug-ins; the Eclipse team can't spend all day testing plug-ins they didn't write, but that doesn't mean that you can't try them out. If one doesn't work, you can always do some investigation, and give the plug-in developer a heads-up
Even if you are feeling adventurous, however, that's no reason to just leave the safety of your stable build and venture out into the wild unprepared. Be sure to take steps to keep your workspace, plug-ins, and other installations protected. I discussed some of the more advanced techniques for running multiple distributions of Eclipse in this Javalobby tip: Managing Multiple Eclipse Installations; which details the steps you can take to ensure that if you do go into uncharted territory, that you don't completely annihilate your environment.
If you decide to download integration builds, you aren't going to get the most bang for your buck unless you know what new features they contain. There are a couple places to look. Every week, Mike Wilson (or a proxy if Mike is off doing something more interesting) summarizes the efforts for the previous week from each team on the eclipse-dev mailing list, which is a low-traffic mailing list for Eclipse developer communication. These weekly summaries typically titled 'Planning Meeting Notes' typically have one-liners about what new features have been released into the wild for the latest integration build. In addition, on the Eclipse website each component of each sub-project has a detailed plan laid out for the next milestone. As an example, here is the 3.2 M5 milestone plan for the JDT Core team. You can typically find these milestone plans by visiting the project homepages. By digging through these milestone plans, you can get an idea of what features are on deck, and by perusing their corresponding bugzilla entries you can usually get a good idea of when they are going to be available from the integration builds. Finally, you can always look over the project plan (3.2 project plan linked) to see what the general direction of Eclipse is for the next release.
As Eclipse users we all have an interest in the direction Eclipse takes. I recently posed the question How Can Eclipse Become the Most Powerful Java IDE?, and the general sentiment that I think can be taken away is that if Eclipse isn't what we want it to be, we have an opportunity to 'take the bull by the horns'.
Now, don't get me wrong, Eclipse already has great feedback from the community. One of my favorite examples of the enthusiastic interaction of Eclipse users was during the road to Eclipse 3.0. Eclipse 3.0 Milestone 6 brought with it a new look and feel that was in a very rough, unpolished state. The community had so much feedback in terms of attachments that they had to move the attachments off of Bug 37997, and open a new one as it was surpassing the capacity of the Bugzilla servers at that time. Across the two bugs, there was over 240 comments, and several other bugs opened to account for the individual problems. In the end, the user interface polish is a largely popular feature of the Eclipse 3.0+ releases, and the community played a central role in ensuring that those who don't like the new look and feel, can just hop into their preferences and go back to the Eclipse 2.1 view of the world.
So, Eclipse definitely has an enthusiastic backing, but it can always be better. Features come up from time to time in Eclipse that are very controversial - some people like them, some people hate them. The beauty of a transparent development process like the one used with Eclipse, however, is that the community has an opportunity to influence and change the direction that is taken.
Until Next Time,
R.J. Lorimer
rj@javalobby.org
|
EZ News Corner
