We maintain a number of different versions of our application, including feature-specific development forks that rely on other feature specific development forks. So for example our primary development fork consists of:
The latter project depends on the first one. In order to work on a particular feature in isolation, e.g. migrating our mail service implementation, I'll fork both of these development forks to something like:
To work with this, you do the fork, then import the projects into a new workspace. The .project file for each project has a name, e.g. xdat for the first, xnat_builder for the second. STS imports the projects from the folder into which they were cloned, with the project name set to (here's where the problem comes in) the name specified in the name element of the .project file. The .classpath file for dependent projects references the name of the dependency project. So in the .classpath for the xnat_builder project, we have:
The problem is that now the projects are being named whatever the folder name is instead of using the value for the <name> element in the .project file. This causes all kinds of issues, but primarily screws with the build path references to other projects, since my /xdat reference is now unresolved, as the project is named xdat_1_5_dev instead of xdat.HTML Code:<classpathentry combineaccessrules="false" kind="src" path="/xdat"/>
This is consistent in 2.7.0 on both Mac OS X and Windows 7. I just tested in a Centos 5.5 VM that still has STS 2.7.0.M1 and it did the appropriate thing there: I imported xdat_1_5dev, which went into a folder named xdat_1_5dev, and the imported project in my workspace is named xdat instead of xdat_1_5_dev.
I would say that this is an Eclipse issue as opposed to STS, since the project import function is in Eclipse, but I know I've seen STS do the right thing (and as I said in 2.7.0.M1 it's doing the right thing), so this has to be something in STS itself.
BTW, as an addendum, if I rename the project so that it matches the correct name in the classpath references, this actually renames the folder as well instead of just changing the <name> element in the .project file. This causes problems because we maintain lots of projects at the same folder level, with the different versions distinguished by the folder name (you can argue that this is a bad organization and I won't necessarily disagree, but it's what we have in place at this point ).