Community
Participate
Working Groups
Hi, I am not sure where this belongs Core/ UI or Debug; however discovered this today, In eclipse I can "Import exiting projects into Workspace", *IF and only IF* the <name></name> in the .project file matches the name of the folder in which it exists. To confirm; I created a Java project in my workspace, by name HelloWorld. Subsquently deleted it from workspace, WITHOUT deleting contents from the file system. Next in the file system, edited ONLY the ".project" file of this project. I changed <name>HellWorld</name> into <name>Not-HelloWorld</name> Returning back to eclipse, tried the command File -> Import -> Import exiting projects into Workspace Specified the folder for the HelloWorld. The Projects list box in the dialog listed Not-HelloWorld. (read the .project file). I selected it and clicked finnish. An error dialog popped up, saying Invalid project description. Detail showed D:\Users\Jeevan\workspace\HelloWorld overlaps the workspace location: D:\Users\Jeevan\workspace. I reedited the .project file manually and restored the <name></name> following which I was able to import it into my workspace. This happens with: Eclipse SDK Version: 3.1.2 Build id: M20060118-1600 But does NOT with a older version. Eclipse SDK Version: 3.1.0 Build id: I20050627-1435
(In reply to comment #0) Yes, following the example I indicate to recreate the bug, there may be no valid reason for editing a .project file. But I chanced on this behaviour cause my .classpath and .project files were created by the maven2 task eclipse:eclipse. ~g1
Moving to JDT/UI
'Import exiting projects into Workspace' is platform/ui
Hi, There has been no change/ action with regards to this bug. I would like to know if it has been accepted and will it be rectified in future versions? thx
Looking at http://dev.eclipse.org/newslists/news.eclipse.platform/msg42442.html it appears that this may not be a bug, and instead an attempt to make sure that paths within the workspace (virtual or real) are unique. What IS a problem is that the error message is utterly uninformative about the root issue (project name doesn't match directory name). I've wasted lots of time tracking this down every few months...
I get the invalid project description error in 3.1.0 Build id: I20050627-1435, so this is not a regression. The UI displays the error messages it gets from Core and it is expanded upon in the details. Also, it isn't always the case that the project name has to match the name of the root folder, as was mentioned in the newsgroup posting that is referenced in comment #5. Moving to Resources to see if they can provide a better error message in this case.
*** Bug 140733 has been marked as a duplicate of this bug. ***
John, feel free to punt back if it is more appropriate that the UI do an additional check, in an attempt to get a more fine-grained error message, before we try to create the project.
The problem here is that creating a project called "foo" in a directory called "bar" in the workspace is not allowed. You can't store a project in the default location for another project. However, the import wizard *could* be changed to use the directory name rather than the name in the .project file as the project name, and then the import would proceed without error. *** This bug has been marked as a duplicate of 40493 ***
I don't think it's accurate to call this a duplicate of 40493. True, if that issue is in fact resolved, then this one should become irrelevant. But if that issue is not resolved (and a comment says it won't be fixed for 3.2) then this issue still exists: the error message is misleading and causes user pain. It should be much easier to fix the error message, and get that fix in 3.2, than to add new features that work around the core error condition.
> It should be much easier to fix the error message, and get that fix in 3.2 We have already declared the final 3.2 build. We are now working on 3.3. In 3.3, it would be more interesting to allow such an import to proceed than to improve the error message.
On further reflection, you're right. This isn't entirely a duplicate of bug 40493. That bug is requesting the ability to change the name of a project on import. This particular error can be solved by using the directory name rather than the name in .project in the case where the project resides in the default location.
Created attachment 45408 [details] Fix Karice, this patch uses the project directory as the project name when importing a project in the workspace directory. Since that is the only valid name for a project in that location, this seems like the correct behaviour.
Thanks for the patch, John. I applied it and just have some minor points to bring up. Do you think it is confusing to have the project name in the list be the folder name instead of what is in the .project file as the name? I think it would be helpful to have the name of the project (in the .project file) followed by the folder name (if different) appear in the list. I am still thinking about a nice way to display this in the list - I haven't thought much about how I would display the folder for projects that are not in the default workspace location. What do you think?
I can see the potential for confusion, but it seems just as confusing to present two names in the list. The behaviour with the patch is actually consistent with how the underlying APIs work. For example if you create a new project called "Foo", but there is an existing .project file on disk in that location whose name is "Bar", then the name in the .project file is ignored and "Foo" is used. I.e., the name in the description is really only a "hint" about what the name should be, but it can be overridden.
Ah yes, good point.
I just found a case where you can have 2 projects with the same name in the import list. If, in one workspace, you have a project called A and a project called B then change the name in the .project file of B to A then (in another workspace) do import project, you will have two projects called A in the list. Should we always use the name of the directory as the name we show in the list of projects to import?
The directory name only needs to match the project name when it is in the default location (a direct sub-directory of the workspace directory). I guess the ultimate fix is to let the user chose the name of each project that is not in the default location from within the wizard (bug 40493).
Ok then, this will hold over until that bug can be fixed. Fixed in HEAD for build > 20060628. Oh, and I changed the title back to what it was originally.
*** Bug 76417 has been marked as a duplicate of this bug. ***
verified in I20060809-0010
