Spring Tool Suite
  1. Spring Tool Suite
  2. STS-1918

Project import ignoring .project file name attribut

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.7.0.RELEASE
    • Fix Version/s: 2.8.0.M1
    • Component/s: None
    • Labels:
      None

      Description

      Issue reported on forum here:
      http://forum.springsource.org/showthread.php?111693-STS-2.7.0-project-import-ignoring-.project-lt-name-gt

      It looks like STS is somehow changing the behavior of the 'Import Existing Projects' wizard to ignore the name attribute in the .project file.

      To reproduce:

      • create a "General" empty project.
      • edit the project's .project file to change the name attribute to something else
      • import this project into another workspace with the "Import existing projects" wizard.

      Observed:

      • the import wizard will use the name of the folder instead of the name in the .project file for the project.

      One might think, this is an Eclipse bug not an STS bug, but a Vanilla Eclipse does not exhibit the problem and correctly uses the .project given name.

      I have checked this with an E362 and E37RC3. Should probably double check also with a 37Release, but did not have one around at the time.

      In any case, it seems there's enough evidence to point the finger at something STS is doing to be the cause of the problem. So should look into it further.

        Activity

        Hide
        Rick Herrick added a comment -

        Note that testing on 2.7.0.M1 behaved correctly. I can see the problem on both Windows 7 and Mac OS X in 2.7.0.RELEASE. My 2.7.0.* versions are all on top of Eclipse 3.6.2, since the updates were installed through the update site, not as a new installation, so it's not using Eclipse 3.7.

        Show
        Rick Herrick added a comment - Note that testing on 2.7.0.M1 behaved correctly. I can see the problem on both Windows 7 and Mac OS X in 2.7.0.RELEASE. My 2.7.0.* versions are all on top of Eclipse 3.6.2, since the updates were installed through the update site, not as a new installation, so it's not using Eclipse 3.7.
        Hide
        Kris De Volder (c) added a comment -

        Right and I checked it on Ubuntu, which is what I'm using. So problem is definitely not OS specific.

        Everything points at a problem with something added to Eclipse by STS. But before I go down the rabbit hole... I just want to establish 100% sure this is the case. So I want to verify that the problem isn't present in the E37 Eclipse that our current STS development branch is based on.

        Show
        Kris De Volder (c) added a comment - Right and I checked it on Ubuntu, which is what I'm using. So problem is definitely not OS specific. Everything points at a problem with something added to Eclipse by STS. But before I go down the rabbit hole... I just want to establish 100% sure this is the case. So I want to verify that the problem isn't present in the E37 Eclipse that our current STS development branch is based on.
        Hide
        Kris De Volder (c) added a comment -

        Hmm...

        Ok I swore I saw the buggy behavior yesterday, but now I'm trying again in STS 2.7.0.Release and it is working perfectly. This is with an STS based on E37.

        Show
        Kris De Volder (c) added a comment - Hmm... Ok I swore I saw the buggy behavior yesterday, but now I'm trying again in STS 2.7.0.Release and it is working perfectly. This is with an STS based on E37.
        Hide
        Kris De Volder (c) added a comment -

        More specific circumstances are needed to reproduce buggy behavior:

        It looks like the name from the .project is used correctly when the imported project's location is not already in the workspace folder.

        So these steps produce the buggy behavior:

        • create project in current workspace
        • rename by modifying the .project file
        • delete project (but not its contents)
        • import project into the same workspace.

        It seems only when importing into the same workspace do I get bug behavior.

        Now also trying these exact same steps in Vanilla Eclipse...

        Show
        Kris De Volder (c) added a comment - More specific circumstances are needed to reproduce buggy behavior: It looks like the name from the .project is used correctly when the imported project's location is not already in the workspace folder. So these steps produce the buggy behavior: create project in current workspace rename by modifying the .project file delete project (but not its contents) import project into the same workspace. It seems only when importing into the same workspace do I get bug behavior. Now also trying these exact same steps in Vanilla Eclipse...
        Hide
        Kris De Volder (c) added a comment -

        I tried with brand new E37 JEE and get the same 'buggy' behavior.

        Rick, it looks like an Eclipse bug once again. Can you try if, perhaps, the reason why this bug is happening for you in STS and not Eclipse is not somehow related to where the imported projects live (i.e. it seems to use the folder name, when the folder is inside the workspace folder on disk but the .project name when the folder is not in the workspace).

        I previously thought that behavior differed between STS and Eclipse because, it so happens, when I started the Vanilla Eclipses, I was also naturally using a different workspace.

        Show
        Kris De Volder (c) added a comment - I tried with brand new E37 JEE and get the same 'buggy' behavior. Rick, it looks like an Eclipse bug once again. Can you try if, perhaps, the reason why this bug is happening for you in STS and not Eclipse is not somehow related to where the imported projects live (i.e. it seems to use the folder name, when the folder is inside the workspace folder on disk but the .project name when the folder is not in the workspace). I previously thought that behavior differed between STS and Eclipse because, it so happens, when I started the Vanilla Eclipses, I was also naturally using a different workspace.
        Hide
        Rick Herrick added a comment -

        I just reproduced the behavior you're seeing, Kris. That is indeed the cause. I'll take this over to the Eclipse JIRA and thanks for helping out with understanding it!

        Show
        Rick Herrick added a comment - I just reproduced the behavior you're seeing, Kris. That is indeed the cause. I'll take this over to the Eclipse JIRA and thanks for helping out with understanding it!
        Hide
        Rick Herrick added a comment -

        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.

        Show
        Rick Herrick added a comment - 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.
        Hide
        Kris De Volder (c) added a comment -

        Well, at least understanding when the behavior goes wrong, you can probably work around it by making sure your projects are living outside your workspace folder. That way it should work as you expect.

        I'm resolving this as "Works as Designed" because it isn't an STS bug.

        Show
        Kris De Volder (c) added a comment - Well, at least understanding when the behavior goes wrong, you can probably work around it by making sure your projects are living outside your workspace folder. That way it should work as you expect. I'm resolving this as "Works as Designed" because it isn't an STS bug.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Kris De Volder (c)
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: