Scala IDE for Eclipse

Facts

1. Egit currently has no support for git submodules and will corrupt repositories which are set up for submodules.
2. Egit currently supports multiple related projects by having them contained within a single git repository.
3. Eclise requires a one-one correspondence between Eclipse projects and OSGi bundles for self-hosted development.
4. git-svn can only synchronize changes between a single git repository and a single standard subversion trunk/tags/branches structure.
5. The IDE projects in EPFL svn currently each have independent trunk/tags/branches structures.
6. Mechanisms for linking multiple git repositories (ie. submodules and subtree merges) are fiddly and error prone and impose a complexity burden on all developers.
7. Assembla supports multiple repositories within a single space, however all but the first have "funny" URLs with an essentially random integer as a suffix.
8. Checking out a large number of repositories simultaneously is fiddly and error prone without scripts (which are platform dependent).
9. git doesn't support partial checkouts.
10. Assembla spaces' dashboards and streams are quite noisy.
11. The core Scala toolchain is huge and rapidly changing.
12. IDE development work only involves infrequent modifications to the core Scala toolchain.
13. IDE development work frequently touches multiple IDE projects.
14. git only supports atomic commits across multiple repositories via submodules.
15. Eclipse development styles strongly encourage multi-project/bundle structures.
16. Compatiblity issues between the AspectJ and Scala Eclipse tooling force the IDE's AspectJ components to be in a separate project.

Goals

1. We want to make it as easy as possible for people to check out the IDE sources and make small contributions.
2. We want to make it easy to track development of the IDE.
3. We want to be able to make atomic commits across all the IDE projects.
4. We want to be able to make atomic commits across the core Scala toolchain and the IDE projects.
5. We want tickets to be shared across all IDE projects.
6. We want to be able to easily add new IDE projects and subdivide existing ones.
7. We want to be able to synchronize all changes between Assembla and EPFLs svn.
8. We want to be minimally disruptive of existing svn checkouts from EPFL svn (one of which is EPFLs nightly build).

Analysis

1. G1 and F1,6 imply avoiding git submodules.
2. G1,3,6 and F2,6,8,13,14 imply that all the IDE projects should be contained in a single git repository.
3. G1,2 and F9,10,11 imply that the core Scala toolchain and the IDE projects should be in separate repositories.
4. A3 and F14 imply that G4 cannot be met. F12 suggest this isn't that big a deal.
5. A2 implies that G5 is met.
6. F3,15,16 imply that there must be multiple IDE projects.
7. A2,6 and F4,5 imply that the EPFL repository structure must be changed.
8. A7 implies that G7 cannot be met and G8 might be tricky.
9. G1,2 and F7,10 imply that the core Scala toolchain and the IDE projects should be in separate Assembla spaces.

Resolution

• We will move the core Scala toolchain git repository to a separate Assembla space (G1,2,5).
• We will combine the IDE projects into a single git repository (G1,3,5,6).
• We will live with the breakage due to the restructuring in EPFL svn that follows from G4,7 not being met.
• We will work with EPFL to ensure that their nightly builds continue to work smoothly (G8).