Bugzilla – Full Text Bug Listing
| Summary: | Import Existing Projects into Workspace ignores project name when importing from workspace location | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eric Jain <eric.jain> | ||||
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||
| Status: | RESOLVED INVALID | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | alec.bickerton, denis.hopp, dooser, john.arthorne, prakash, pwebster, rherrick | ||||
| Version: | 3.6.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=465206 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The folder from where Eclipse imports, may contain multiple projects. So when 'Copy Projects to Workspace' is checked in the Wizard, the folder in the workspace is created with the project name. This is normal and I don't see a bug in it. (In reply to comment #1) > The folder from where Eclipse imports, may contain multiple projects. So when > 'Copy Projects to Workspace' is checked in the Wizard, the folder in the > workspace is created with the project name. This is normal and I don't see a > bug in it. This bug isn't about names of folders that are created (the 'Copy Projects to Workspace' option is not used). The bug is about Eclipse ignoring the project name set in the .project file when importing a project that happens to be located in the workspace directory. See discussion on the bug 143757, especially bug 143757 comment 9. (Code referenced: WizardProjectsImportPage$ProjectRecord#setProjectName()) This is a terrible resolution to this issue. There are a few problems with this: * The primary issue in the discussion is basically namespace collision: having two projects of the same name within the same workspace. In cases where that arises, raise a warning during the import of a project with a folder name that duplicates an existing project. Give the user the option to rename the existing or incoming project or to stop the import. * I can also duplicate project names within a workspace without having the two projects in the workspace folder. The issue is already there. * Currently the behavior differs, completely without explanation, when you import from a workspace folder as opposed to when you import from a non-workspace folder. That's terrible behavior. If it's going to do the same operation inconsistently depending on context, then there needs to be a warning of some sort that you're doing that and an explanation of how to work around it. * The biggest problem with this is that it BREAKS CROSS-PROJECT DEPENDENCIES. For example, you have two projects, Project1 and Project2. Project1 is a dependency of Project2. Project2 thus has an entry in its .classpath to /Project1. Now I branch my code and extract those two Project1.branch and Project2.branch. I import into my workspace and now Project1 doesn't build because it's called Project1.branch and (more importantly) its dependency is called Project2.branch. I either have to modify the .classpath file for Project1 (prompting a change in the SCM) or rename Project2.branch including the folder. This is quite an obscure and confusing behavior, which caused me to lose a couple of hours trying to figure out why my projects weren't getting set up properly. You either need to make it work the way that it SHOULD (i.e. observing the value of the name element in the .project file and let me be a big boy and worry about namespace collisions) or at least raise a warning when you go about changing project and folder names. To get an idea of how this appears to people who are unaware of the behavior, check out the progress of this forum post and bug filed against SpringSource Tool Suite: http://forum.springsource.org/showthread.php?111693-STS-2.7.0-project-import-ignoring-.project-lt-name-gt https://issuetracker.springsource.com/browse/STS-1918 Just spent half a day comparing configuration from my machine to my co workers, recreating projects and re-installing eclipse. Eventually tracked it down to this bug. I agree with Rick, calling this invalid is a "Terrible Resolution". While it might not be common for most users, I very frequently check out a set of projects from source control directly into the root of my workspace and then immediately import them. A warning would have been nice. At the very least there should be some communication to the user that this is a special case and the values in the .project are being ignored. This should simply be marked invalid as this behaviour breaks the workflow of many projects. For example it's a normal workflow to check out a project directly into the workspace using Subclipse or Subversive. If the .project file name is suddenly being ignored, this will break the various build scripts in use. This should NOT simply be marked invalid as this behavior breaks the workflow of many projects. For example it's a normal workflow to check out a project directly into the workspace using Subclipse or Subversive. If the .project file name is suddenly being ignored, this will break the various build scripts in use. How can this be invalid? There is an undocumented difference in behavior depending on the location on the file system. This is very poor design if it is "working as intended" Being able to change the name during import is covered under bug 40493 If someone would like to contribute a warning that could be done under this bug, re-opened. PW *** Bug 486549 has been marked as a duplicate of this bug. *** |
Created attachment 194392 [details] Test Project Extract the attached project into a folder somewhere outside of the workspace directory. Then import the project using "File" > "Import..." > "Existing Projects into Workspace". The project name is "Test Project", as expected. Delete the project from Eclipse, and move the "foo" directory that contains the project into the workspace directory. Repeat the import. This time Eclipse ignores the project name set in the .project file, and uses the directory name "foo" as the project name. Also, when renaming the project, the directory containing the project is renamed. This behavior differs from when renaming a project that is not located in the workspace directory, where only the .project file is updated.