Managing Eclipse with large development teams

Tom Tromey’s post about the challenges of packaging & distribution Eclipse plugins, is symptomatic of a much larger management problem in Eclipse. A little while back I was involved in designing & implementing a structured development environment for a group of (~20) Java developers. The model was to have a handful of remote servers setup to allow developers to remotely run Eclipse within a VNC desktop. There were three core goals I was aiming to hit:

1. Ensure all developers are using an identical development environment / toolchain. So using the same JVM version, populating Eclipse with the same plugins, using the same workspace settings, have the same code checkout.
2. Enable new developers to get working with a fully functioning development environment in < 10 minutes. This includes creating a new Eclipse workspace, getting a complete code checkout, building the code & finally be able to run the application
3. Enable new machines to be installed & correctly configured to act as development servers with no manual intervention.

While the base RHEL OS build was easily installed & configured with Anaconda’s automated kickstart capability, the deployment & subsequent management of Eclipse, is much more complicated. The crux of the problem is that the model Eclipse (and most other IDEs) operates under, is focused on individual developers. The update manager is one example of this mindset – each developer is expected to individually download & install the plugins they want in their workspace. When a plugin update comes out, each developer has to individually update all their workspaces. When managing a large development team a top priority is to ensure all developers have the same version of all the tools – you don’t want them wasting time debugging problems caused by different tool versions. As an administrator it should be possible to deploy & upgrade plugins for all developers using the regular RPM+YUM model. I partially addressed this by deploying RPMs which install the plugins to a central directory & instructing developers to simply have the update manager install all plugins found at this location.

Configuration of the Eclipse workspace was another big problem. While many settings within the IDE can be classified as “personalization”, an equally large group are what I’d term “functional” (ie they affect the way the application builds). To complicate things a little further, the settings are split up, some associated with the workspace, others associated with individual projects. With the “functional” settings, it is clearly critical to ensure all developers within a project are using the same configuration to avoid wasting time debugging build problems. At times during development of a project, it may be neccessary to adjust some of these “functional” settings; at these times one needs to ensure all developers’ workspaces are updated in a consistent fashion. While Eclipse lets one store the .project files within SCM, there is no facility to manage the enclosing workspace configuration. Storing the .project files within SCM was not a perfect solution either, because it was all to easy for a developer to inadvertantly make changes to the .project file & commit them to SCM, impacting the entire development team. It is possible to import & export workspace settings in a plain text file, however, this does not scale up – it is impossible to ensure all 25 developers have the latest requisite settings file imported.

Getting new developers up & running was a similarly challenging exercise in workspace configuration. There was a painfully long set of manual steps, creating a new workspace, importing a file containing workspace settings, installing extra workspace plugins, configuring an SCM repository, checking out the requisite set of projects from a particular SCM branch. A mistake at any point in the process could result in a huge time sink trying to figure out why the developer could not get the application building in the same way as other team members.

It all really comes down to a question of policy & control. As the manager of the development environment, one should be able to define a “template” workspace which contains all the pre-determined functional settings, loads the neccessary set of plugins, defines the appropriate SCM repository & listes requisite projects. Getting a developer up & running would then merely require invoking a command to the effect of “give me an instance of this workspace template”. With such a capability, new developers would be up & running in a matter of minutes. With all manual setup processes eliminated, one can be sure the developer’s environment is consistent with the rest of the team & they can get straight into doing useful work on the project itself, rather than wasting time on setup.

While Eclipse is a very powerful & flexible tool, there is a very large price to be paid for this, with a great burden placed on individual developers to manage the workings of the IDE itself. This diverts attention from the core goal of getting useful development work done. As the size of a development team grows the management overhead has increasingly detrimental impact on the team’s productivity. To address this problem, IMHO, future Eclipse development needs a much greater emphasis on addressing the management needs of teams, rather than individual developers.