| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| <html> |
| <head> |
| <title>Library projects</title> |
| <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css"> |
| </head> |
| <body text="#000000" bgcolor="#FFFFFF"> |
| |
| <table width="100%"> |
| <tr><td style="background:#0080C0"><b><span style="color:white">Library projects</span></b></td></tr> |
| </table> |
| <font size="-1">Last modified: January 20, 2006</font> |
| <p> |
| <h3>The Problem</h3> |
| <p> |
| 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. |
| </p> |
| <h3>Proposed Solution</h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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). |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3>Open Problems</h3> |
| <p> |
| <ul> |
| <li>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.</li> |
| <li>Will it be confusing that modifications to source in a library project have no effect?</li> |
| <li>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?</li> |
| </ul> |
| <h3>References</h3> |
| <p> |
| Plan item <a href = "https://bugs.eclipse.org/bugs/show_bug.cgi?id=80162">bug 80162</a>. |
| </p> |
| </body> |
| </html> |
