There used to be an age-old restriction in Eclipse whereby two projects couldn’t be imported into the same workspace if the project locations overlapped in the file system. So if you had a project hierarchy like
Then you couldn’t have a workspace that looked like this:
I say ‘age-old’, because (obviously) somewhere along the line this workspace restriction was removed, maybe at the behest of WTP – I’m not sure, I can’t find the related Bugzilla entry (UPDATED: John Arthorne has indirectly pointed me to it – Bugzilla 44967). I only noticed last night when I was just about to blog about how nice it would be to be able to do this. It would appear I am very stuck in my ways – until now I’ve always used separate workspaces to work on the my top level projects and that doesn’t sit too well with trying to use Mylar.
By top level projects I mean a simple project (with no builders/natures) that contain the Ant/PDE build scripts and multiple sub folders, each containing a set of projects (plugin or plain Java) that represent the modular components of our products. These projects are usually big, whole CVS modules in fact, but by synchronizing them with our CVS repository we can easily detect build script changes that might require us to do a little more than re-build each plugin project in our workspaces in order to pick up all of the latest changes.
There is one trick to using this arrangement. Always make sure that you put at least one non-project folder in between your top level project and the contained projects. That way you can check out the top level project, and then point the Eclipse Import “Existing Projects…” wizard at the intermediate folder and it can auto-import all projects found in sub-folders. If you point it at the top level project it will do nothing, thinking you already have that project in your workspace.
Anyway, this is all great good news for anyone who wants to use Mylar with a project arrangement like this since it means that if you need to tweak build scripts as well as plugin source code (which I very frequently do), then you can do it all in one workspace and Mylar will keep track of everything you are doing . This is great for building change sets, especially so for committing changes back to CVS!
There is one caveat though, but only if you check your projects out into your workspace folder folder and I think a lot of people do this. If you try to subsequently use the New Project wizard to try create a “contained” project (like the ‘inner’ one illustrated above) then you will hit a problem. When you deselect the “Use default location” check box for the second (contained) project, the wizard will flag an error claiming that the “Project contents cannot be inside workspace directory”. I have no idea why it does this since this the suggested default is in the workspace folder but it’d be nice if the platform guys could fix this. It must be a trivial fix, I’m guessing it’s doing an indiscriminate “location.startsWith()” validation check on the string or something (see Bugzilla 165336. (UPDATE 2: it looks like the UI bug is fixed for 3.3 – see Bugzilla 147727)
A workaround is to create the project elsewhere, delete it from the workspace (but not it’s contents), move it on the filesystem and then re-import it into the workspace…