If I may be so bold, I think that if you're running Eclipse on three different workspaces at once, you may have misinterpreted what the word "workspace" implies!
Interesting point, but no - I'm forced to do this because that's the way that Eclipse wants you to do it. Eclipse wants to do various things on "all projects in the workspace" by default, and after trying to fight in (with only partial success) eventually I twigged why: An eclipse-workspace is what most people used to working on large projects would call a project (i.e. "one or more tightly related libraries", or "all the components of a large componentized application") and that an eclipse-project is what most people would call a single component (i.e. something that they JAR into just one JAR) - e.g. "a single self-contained library".
Now, I have:
1 a base engine project ( 8 JAR's) == one workspace
2 a CMS project (4 JAR's, runs on top of base engine) == another workspace
3 JGF server (1 JAR + N other JARs to add extra content/features later on) == a third workspace
The annoying thing is that I only very occasionally even need to even look at workspace 1 (usually to tweak some code that the CMS project is exercising in new ways, or to refactor something between the CMS and the base engine).
Whilst doing JGFv3, I often need to edit the CMS project (because this project is being brought to production-quality roughly in parallel with JGFv3).
But if I put all in one workspace I get the following problems:
- workspace has far far too many eclipse-projects in it to be manageable. Far too many open files at once for the navigation to be easy
- every time you change a base file, it reparses EVERYTHING, and you can end up waiting a long time for the reparse to chain through all those dozens of projects
- ...which is stupid, because the three workspaces are INDEPENDENT projects (in the real world sense) that just happen to link together at runtime.
But, thankfully, by having multiple workspaces I can insulate the various projects from each other.