In Classpath we’ve narrowly avoided most of the team-related
Eclipse problems Daniel
Berrange mentions encountering.

Partly this has been because we’re all mad free software hackers,
and so we don’t even try to ensure we all have the same tools.
Instead folks doing development in Eclipse have a choice of operating
systems and of virtual machines (both jamvm and cacao work nicely in
this environment).

Over time Eclipse has gotten better at separating the personal
from the project — Eclipse 3 is much better than Eclipse 2 was here
(e.g. now you can store the coding style for the formatter in the
project). And, we do make an effort to set things up so that typical
uses won’t require any changes to the project metadata; that both
avoids unpleasant accidents and lets people in different environments
continue to get sane results. Partly we’re able to do this because we
have an unusual hybrid build which includes autoconf (this isn’t
without its bad qualities as well).

We put a fair amount of effort into making our setup turnkey.
There’s a
nice web page on the wiki which explains, step-by-step, how to get
set up for working on Classpath. This is still a lot harder than we’d
like, but it can be done in thirty minutes or so if you’re already
familiar with Eclipse. I demoed this at FOSDEM this year; most of the
time during the demo was spent waiting for the build (Classpath is
over a million lines of code, so that can be forgiven). In real life
you also spend some time waiting for the network — my demo was with a
local cvs server.

Also, supposedly team sets help a bit here. As I understand it a
team set is a way to specify a group of projects to check out. My
brief experiment here was a little un-promising; I think it picked the
wrong user for CVS repositories by default (I was hoping it would know
that when I used “anonymous”, I wanted the end user not to have to
specify a username). Someone in the Classpath community (I forgot
who, sorry) did make a team set but then it never ended up on the
wiki… (ping).

As a user you do have to watch out a bit. I once installed the
FindBugs plugin, and then to my dismay found out that it modified the
project builders. This is unacceptable; I had to remove the plugin to
avoid accidentally contaminating the shared build. (Any plugin
architecture suffers from problems like this, though. Allowing
plugins means giving up centralized quality control.)

For what it’s worth, our “initial setup” problems with Eclipse
haven’t been much better or worse than the problems we’ve had with
shell-based builds. Eclipse could definitely improve here. (Once
you’re set up, of course, the difference is startling.)

Ideally Speaking

My ideal setup for these things would involve more integration
between Eclipse, the OS, and the organization.

It would be nice if a project could specify required plugins; when
checking out the project Eclipse would first launch the update manager
to install them. In this ideal world, the update manager would work
with RPM rather than stand perpendicular to it.

It would also be very nice to have rendezvous support or the like;
the idea being that in a typical organization you would simply launch
Eclipse and not have to figure out where the version control server
lies. In the free world an analog would be the ability to click a
link in Mozilla and have the repository automatically show up in
Eclipse. Every project’s home page would have a big “Hack Me” button
which you would click to get a working development tree. Or, you
could have Eclipse interface to irc and pick up on repositories and
update sites that way… join #classpath, get a dialog asking if you
want to access the classpath team set.

This latter idea gets to something that bothers me about
programming. Computers are powerful communication devices, and a huge
part of our jobs entails using them to communicate. However, much of
this communication happens at two extremes — there is the extremely
unstructured form like email or irc; and there is the overly
structured form, like a cvs commit. I’m hoping for a generation of
tools that is a bit more loose; tools that notice interesting things
without too much interaction or attention on my part; and also tools
that let me more easily wire up communication the way I need it (my
perennial example here is the amount of time I would’ve saved over the
years if only we could simply drive the debugger over irc).

There’s some work in this area. Eclipse has ECF, NetBeans has its
thing, whatever it is called. There’s also the Jazz project for
Eclipse, from IBM. This isn’t open source (it may be someday), but I
hear the demo is quite cool. It sounds a little too
command-and-control for my taste, perhaps, but I’d imagine it can be
made a little more peer-oriented.

Naturally, none of this is available on the timescale I want,
namely last week.