- Release environment - The cost to add a project or module tracks linearly to the number of projects or modules added. In the release environment there is a lot of flexibility in how a release job is configured. For example, one job could build several modules.
- CI environment - An increase in the number of modules typically has a non-linear cost in the CI environment. Unlike the release environment, we do not typically group modules in a single job, but assign a unique job to the smallest unit of source that produces a jar (i.e. .
- development Eclipse project configuration
- An approach to managing modules in Eclipse: Consider that an Eclipse project (little p) maps neither to a Project (big P) nor a Module, per se. An Eclipse project then represents a view of one or more projects and/or modules. Given that assertion, we could present a much more clean view into developing the platform than we have in the past. For example, a developer may now see only 5 Eclipse projects instead of 15, where each of the 5 Eclipse projects manages 3 modules. We could make this work by having platform SVN "master" folders like we do with plugin-actions. Plugin-actions would be comprised of a number of self-contained modules which manage their own dependencies via unique ivy.xml files. The master project, plugin-actions, could then have a generated ivy.xml that includes the various module ivy.xml's to give Eclipse IvyDE developers a useable project.