Community
Participate
Working Groups
1. File > Import > General > Existing Projects into Workspace > Next 2. Select archive and browse to a zip file that contains a zipped project, then click Finish. 3. Repeat process: File > Import > General > Existing Projects into Workspace > Next 4. Select archive Browse to the same exact zip file Result: File gets selected, but Finish button is disabled so you can't import and overwrite. Expect: Ability to import and overwrite.
Indeed this behavior should be improved. I think that when project with the same name exists already in the workspace there should be an appropriate message shown. Also there should be a checkbox "Overwrite existing project in the workspace" which would be enabled only in this situation This checkbox would indicate that the project from the workspace should be overwritten by the project from the archive file.
Created attachment 59481 [details] Patch attachement I have created a patch for this. I have added a checkbox, which indicates if the project should be overwritten. This works both with importing from archive and from normal directory. I'm waiting for any review.
I haven't reviewed all of this, but here are two things that need to be addressed: 1. Using COLOR_GRAY and COLOR_BLACK only works when normal system colors are used, but would screw users that use high contrast mode (inverted colors, big fonts). You should instead use something like this: RGB dimmedRGB = blend(treeControl.getForeground().getRGB(), treeControl.getBackground().getRGB(), 60); 2. When deleting projects that the user chose to overwrite, you don't report progress properly. Make sure that regardless of the control flow, the total amount of worked() matches the number of units passed to beginTask. Instead of using SubProgressMonitor, consider using SubMonitor, which is a newer class.
Created attachment 61373 [details] Patch attachement I tried to change the patch according to Boris comments. I'm waiting for any remarks.
Not sure if I will have time for this in the M7 cycle.
Sorry, I'm completely swamped.
I'll try and have a look early in 3.4.
*** Bug 194648 has been marked as a duplicate of this bug. ***
I was just listed as an interested party of this bug. What I'm more interested in is not to overwrite the existing project, but rather, a wholesale "Why this project can't be imported into the workspace." dialog. Here's my original comment: When using the "Import Existing Projects into Workspace" dialog box, after entering a directory where projects exist, the list of projects does not show any projects whose names already match projects in the workspace. I can understand that you don't want to projects with the same name; is it possible, however, to at least display the found entry as unimportable? Making that dialog a little easier to understand would be helpful. One possible solution: Add to the Projects dialog those projects that are found but can't be imported, and when selecting one of those, give information why it's not importable in a status label.
(In reply to comment #9) > > One possible solution: > > Add to the Projects dialog those projects that are found but can't be imported, > and when selecting one of those, give information why it's not importable in a > status label. This is exactly what my patch does - already existing projects are grayed out. Moreover there is a checkbox which enables user to overwrite chosen already existing projects.
That's great. Thank you for clarifying my confusion.
*** Bug 202255 has been marked as a duplicate of this bug. ***
Jakub this patch is out of date - could you attach a fresh one please?
*** Bug 173994 has been marked as a duplicate of this bug. ***
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
I think the state of this bug has changed. Graying out of projects that cannot be imported is already available in Eclipse 3.5. There is a warning that some projects cannot be imported. Basically, projects open in the workspace cannot be imported by current implementation. The overwriting is not yet supported. What remains open and malfunctioning is when a project is in the workspace directory physically, but not open in Eclipse workspace. Trying to import a project with the same name from archive is not blocked. Such project should be grayed out as with projects open in the workspace. Similar case when importing a project from other location and with copy checkbox set. If such project is physically in the workspace folder, the operation should be blocked. This behavior aligns with the current implementation. My colleague will prepare a patch for this shortly. Based on the bug title, this fix is more related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=173994, but it is marked duplicate, so I post here. Perhaps, we should reopen it and here handle only the overwrite checkbox feature, if we still want to add it...
Created attachment 182808 [details] This patch grays out the project name if a directory with the same name exists in the workspace location When importing a project into a workspace,the workspace location is being checked for a directory with the name same as the project name. If the "copy projects into workspace" checkbox is checked on, the project name is grayed out, so that there won't be any conflict between the imported project and the directory that already exists there.
(In reply to comment #17) > Created an attachment (id=182808) [details] > This patch grays out the project name if a directory with the same name exists > in the workspace location This patch doesn't address the original problem - the ability to overwrite the proejcts. But the patch does solves a different problem - Bug#330553
*** Bug 344771 has been marked as a duplicate of this bug. ***
see Bug 398819 the juno implementation now breaks, if the user selects the "root directory" radio button and unchecks "Copy projects into workspace" and then goes back to importing the project.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
