Community
Participate
Working Groups
in 0513 I am trying to get some existing projects into my workspace. I want them actually imported (i.e., copied) into the workspace location. It appears that the only theoretical way of doing this is zip it up and then import from the zip. Ok, so I zipped them up in a structure that looks like foo.zip bar/ .project ... project stuff ... fred/ .project ... project stuff ... ... When I import existing projects from that zip I get a workspace project sturcture like workspace/ bar/ .project bar/ .project ... project stuff ... fred/ .project fred/ .project ... project stuff ... ... The directory sturcture from the ziup is not being trimmed.
I wasn't able to reproduce this using the following steps. Steps: 1. Select a group of projects in workspace1 2. File > Export > Archive File export as a zip file 3. In workspace2 File > Import > Existing projects and import the zip file Result: Structure is bar/ .project ... project stuff ... fred/ .project ... project stuff ... ... This also worked for me with tar files. Does this sequence of actions reproduce the bug for you?
Created attachment 21641 [details] archive to import projects from I don't export the projects. someone just zipped up a workspace and gave it to me. I want ot import the projects. See the attached zip. It seems that importing also leaves the zip file open as i cannot rename the file afterwards.
Note also that this should work at arbitrary depths. The original zip I got contained paths like a/b/c/myProject. This should materialize in the workspace as myProject with all the direct children of a/b/c/myProject as direct children of the myProject project.
Thanks for the test case, I don't seem to be getting exactly the same behavior you are but what I am getting is definately a bug. When I try importing your test.zip (or a test.tar with the same contents) only the first project, com.ibm.rcp.core.configuration, is imported. What seems to be happening is the call List children = provider.getChildren(entry); //$NON-NLS-1$ (that comment can probably go:) in collectProjectFilesFromProvider is only returning a single directory "com.ibm.rcp.core.configuration" when it should be returning the entire list. I'm going to look into this and see if I can find out what's going on.
I found bug 96704 while looking into this. It looks like a separate issue from what you reported initially though it showed up in the test case you posted.
Oh yeah, other than bug 96704 I didn't see any incorrect behavior in your test case, com.ibm.rcp.core.configuration is the only project there that has a .project file, in fact the only two files in the entire zip were com.ibm.rcp.core.configuration/.classpath com.ibm.rcp.core.configuration/.project All the rest were empty directories, perhaps the zip got misgenerated?
Hi, I've had the same problem just a few minutes ago. I've zipped up my complete workspace and gave it to one of my colleagues. He did a "File->Import->Existing Project from Workspace" and chose the supplied zipfile. He ended up in having the same as above: <projectname> --.project --<projectname> ----.project ----.classpath ----src So I tried to import it again on my workstation into a clean workspace. And it worked flawlessly. So we did a few other tests: He exported -> tried to import --> same problem He exported -> I imported --> works OK I exported -> I imported --> works OK I exported -> He imported --> works OK Whenever we uncompressed the zip on his machine and imported it from there it worked also. So, heres my assumption: My system is running on Linux. He is running on Windows. Could that be the problem? It doesn't look like a cross-platform problem because I can read his exported files, or what do you think? FYI we both use I20050527-0010 :) This was my first bug comment. I hope it's helping :)
Thanks for the comment, it helps in sense that I'm definately confused now :) All I can think of is the fact that ZipLeveledStructureProvider declares private ZipEntry root = new ZipEntry("/");//$NON-NLS-1$ whereas the root level separator for windows would be "\" I'm not really sure if that code interacts with the file system or if zip files have their own file separate file structure but that's the only code I could find that seemed OS specific. If it is the problem the fix should be as simple as changing that line to private ZipEntry root = new ZipEntry(System.getProperty("file.separator")); //$NON-NLS-1$ However I don't have access to windows so it's kinda hard for me to tell what's going on. Jeff, were you running windows when you reproduced the bug? Has anybody seen this on linux or another OS?
some answers. - I believe that all machines involved in my case are running Windows (I got the original zip from someone else and cannot be 100% sure what they are running as they are noe around right now). so, don't rule it out but... - The Zip was not corrupted. I used WinZip to delete all of the real content and left only that .project and .classpath. Winzip tends to leave the dir structure around but not show it to you. The problem I was getting occurred on the original zip as well. - random thought, some zips have Entries for dirs and some do not. I have never looked at the import code but it might be that if you get a zip that has entries for the dirs then things fail (or vice versa).
Sorry for the confusion I have probably caused but I had a small bug in my bug comment :) Of course, when I exported the workspace and he imported it there was also a problem. That was the reason for my bug report after all :) So, to sum it up the error occured whenever we tried to import a zipped project/ws on a windows machine. @Aaron If I find the time today I will try your "fix". I have the 3.1RC1 source on my machine.
> If I find the time today I will try your "fix". I have the 3.1RC1 source on my > machine. Hi, I applied the fix to ZipLeveledStructureProvider. But unfortunately it didn't help. We still have the same problem. So if there are any other ideas I'll gladly help. Just contact me :)
I believe I'm seeing this problem as well. I select a project, and export "Archive file". Then I delete the project and try import "Existing Project into Workspace". The project is detected and is imported, but all of its contents appear in a subdirectory (e.g., the project file for "Sandbox" appears as "Sandbox/Sandbox/.project").
I can reproduce it on Windows XP but not on RHEL3 so I can confirm that somehow this is platform specific.
As a note, I was using Windows XP and was exporting and importing using ".tar.gz".
Created attachment 22095 [details] Fix The problem was actually that we were assuming File.separatorChar was the correct separator to use for path names from the archive file. This is wrong. ZipEntry and TarEntry both use '/' as their separators. This patch fixes the problem for me with importing projects on Windows XP.
mvm, OK for RC2?
I'd like to see some tests attached with this fix which create projects from zips in all the "supported" formats just to ensure we don't break anything in future as the exact supported modes are not documented yet, and also that we are explicit in the user doc (and other messages) as to what you can do here. If this is possible then I'm ok for RC2
*** Bug 97954 has been marked as a duplicate of this bug. ***
I released the fix for the original problem for RC2. I am keeping this bug open until we have some tests.
While you're working on this feature, I would like to suggest one minor fixup for the "Import -> Existing Projects into Workspace" wizard. On the Import wizard window, at the stage where I Select the wizard, the description for "Existing Projects into Workspace" says: Create new projects from an archive file or directory. This does not copy the project into the workspace. Well, that's not correct if you import from a Zip file -- it certainly does copy the project into the workspace in that case. Here's a possible rewording: Create new projects from an archive file (files are copied) or directory (no files are copied). Thanks for listening.
Chris - the description for this bug has changed in Eclipse 3.2. I am marking this as resolved against 3.1RC2 and opened bug 149760 to track adding tests for this.
