The Problem

Eclipse users often have a large number of projects in their workspace. Typically a small set of these projects are under active development, and the remainder are just present for the purpose of browsing or because they are required to build, launch, or test the projects being developed. However, the workspace still performs the work of tracking changes in these projects, and performing incremental builds. Similarly, language tools such as JDT expend effort to maintain their model of the state of those projects, and to rebuild search indices as the projects change. Much of this overhead could be reduced or eliminated if there was a way to configure a project as a library project that is not under active development in that particular workspace.

Proposed Solution

Support could be added in the resource API to put a project in library mode. A project in library mode will not respond to incremental build requests, either from auto-build, or manual incremental builds. When entering library mode at the GUI level, the user will be encouraged to perform one final build on the project to ensure its built state is up to date. Users will be discouraged from modifying source artifacts in projects in library mode via the resource modification validator.

When a project is in library mode, language tools are encouraged to no longer track the state of source artifacts in the project. Built state can still be referenced for purposes of compiling non-library projects in the workspace. For example, JDT would no longer maintain its Java model based on the project source, but rather treat the project's output directories as library folders. Changes to built artifacts such as class files, JARs, and DLLs would still be reacted to. Changes to source artifacts would be ignored (with appropriate warning at the time of modification).

When a project is removed from library mode, the user is encouraged to perform a full workspace build (or if autobuild is on, it will just happen without user interaction). Library projects will receive a full build, and all downstream projects will be built incrementally.

Open Problems

• Is there a significant benefit to designating a project as a library project? Are users well served by the current scoped build mechanism as a way to reduce the cost of building a large workspace? We have had no feedback on the plan item bug.
• Will it be confusing that modifications to source in a library project have no effect?
• Should there still be a way to force a build of a library project? Does it make sense for global workspace builds to ignore library projects, but still build them when a single project (or group of projects) is selected for compilation?

References

Plan item bug 80162.