Large-scale development issues
Last modified: February 24, 2005

One of the major development themes for Eclipse 3.1 is to improve support for "Large-scale development" in Eclipse. This includes improving collaboration for large, distributed teams, but it also encompasses support for large workspaces. This document captures requirements submitted in bug reports, mailing lists, and other discussions from people using Eclipse for large-scale project development. Not all of these issues are committed to be solved in Eclipse 3.1, but this list presents, in no particular order, a problem scope from which work items can be chosen. Some of these items are already present on the Eclipse 3.1 plan, but are included here for completeness.

1. Memory footprint

Eclipse imposes a significant RAM footprint when working with a large workspace. Identify principal areas of memory consumption and explore opportunities to reduce current footprint.

2. Performance of I/O-bound operations

Large teams often store development artifacts (code, diagrams, documentation) on a network file system in order to increase reliability, facilitate backup and restoring of data, and to simplify integration and building. I/O-bound operations in Eclipse are typically much slower in such environments. Explore optimization of I/O-bound operations, and moving lengthy operations into a background thread.

3. Project interchange

Eclipse has always emphasized first-class support for integration of repository tools, and has treated repositories as the primary vehicle for code sharing among team members. This leaves behind groups that either don't use a repository, or don't use a repository that has Eclipse integration plug-ins. The Import/Export wizards are typically used by such groups to share code. Some improvements to the import and export tools would them more powerful as a project interchange (sharing) mechanism.

4. Support for non-incremental builders

The workspace builder infrastructure is designed primarily with efficient incremental compilers in mind. Auto-build is turned on by default, and this is only realistic for fast builders. The workspace should have support for inherently non-incremental or slower builders (such as C compilers and Ant-based builders). In particular, we need to support users working in a heterogeneous environment with some fast incremental builders and some slow non-incremental builders, sometimes with both on the same project (bug 60803). Read the proposal.

5. Improved working sets

With very large workspaces, working sets are often used to filter the amount of information showed in various views, and for scoping long-running tasks such as builds and searches. The current working set support has some problems:

item is under development. item is under investigation.
item is finished. ( ) item is time permitted.
[>3.1] item is deferred. new