STS 2.7.0 project import ignoring .project <name>

[rherrick]

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:

• xdat_1_5dev
• xnat_builder_1_5dev

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:

• xdat_1_5dev_mail
• xnat_builder_1_5dev_mail

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:

<classpathentry combineaccessrules="false" kind="src" path="/xdat"/>

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.

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 ).

[Kris De Volder]

One difference between 2.7.0 and the older versions is that we are now on Eclipse 3.7. You could try to see if installing the 2.7.0 release from update site into an Eclipse 3.6 will get you the desired behaviour. For the moment, we are still supporting E36, but you have to install from update site.

[rherrick]

Thanks for responding, Kris.

I've actually been updating my STS installation from an update site since 2.6.1.SR1, per Martin Lippert's directions in this forum post. So as it happens, I'm actually still on Eclipse 3.6.2, if I'm reading the versions correctly from my installation. That's what's weird about it and why I think it's an STS issue: Eclipse hasn't changed at all, just the STS components installed.

[Kris De Volder]

It sounds like you should be submitting a bug report in the STS Jira issue tracker. Since, as you say, with all the info provided here, it seems like some kind of bug/refression introduced by STS. I only suggested trying installing on top of E36 because you seem to suggest that it was an Eclipse issue...

When you raise a Jira issue, please be very specific as to the method via which you are importing a project (this isn't quite clear to me yet, though I would guess you were using "Import Existing projects" Eclipse wizard). If possible provide a simple sample project.

In any case, be very specific about which wizard you are using to import, and the type of project, since, most likely its a bug in that particular wizard and may have something to do with special handling for that particular project type.

Kris

[Kris De Volder]

Well, I decided to quikcly try something.

I used the 'Import Existing Project' wizard and imported a 'General' project into Eclipse after having changed the name in the project description file.

I'm seeing exactly the behavior you describe.

Now... seeing that this is all very 'Vanilla' Eclipse functionality, I am quite hard pressed to imagine how this can be an STS bug. I'd venture no STS code is actually being called in using any of this functionality. It could just be some change in the behavior of the Wizard that happened when something in Eclipse itself got fixed / patched.

If that's the case, and you feel very strongly that this is bug, you probably should raise an Eclipse bugreport for it. Try out in a Vanilla Eclipse. If it has the same behavior, then its not something you should expect STS to be fixing.

[Kris De Volder]

Hmm. I just tried some old Eclipses I had sitting around. An E362 and an E37RC3 and both of those are doing 'the right thing'. So pointing more and more the finger at STS here :-)

[rherrick]

Heh. I would do a bug report, Kris, but you keep getting ahead of me Should I go ahead and file a JIRA on STS for that?

Update: I meant to add, you're correct in your supposition that I was importing the project with the standard Import->Existing Projects into Workspace function. That's why I mentioned that I thought this would be an Eclipse issue, but since I got Eclipse to do the right thing (which you've verified) and only seen it changed from 2.7.0.M1 and earlier to 2.7.0 (I don't know if this was happening in 2.7.0.M2 and I don't have it available to test), I figured it had to be related to something STS is doing.

Let me know if you need any more info or if I should file a JIRA.

[Kris De Volder]

Since I had enough info to reproduce the problem I raised a Jira issue: https://issuetracker.springsource.com/browse/STS-1918

I'll look into it further. You can put further comments and follow up with the Jira ticket.

[rherrick]

This is a known bug at Eclipse marked RESOLVED INVALID. I added a comment letting them know that I ah... respectfully disagreed with both their reasoning and their implementation.