Bug 579240 - [import] Import 'Projects from Folder or Archive' silently ignores failure to import already imported projects
Summary: [import] Import 'Projects from Folder or Archive' silently ignores failure to...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 4.20   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-03-13 07:11 EDT by Dennis Hendriks CLA
Modified: 2022-03-13 11:47 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Hendriks CLA 2022-03-13 07:11:36 EDT
Steps to reproduce:

* File -> New -> Project... -> General -> Project -> Next. Use 'project1' as name.  Click 'Finish'.
* Outside Eclipse, find the folder for the new project, and copy it from from 'project1' folder to 'project2'. Keep all the files both folders unchanged. The '.project' file in the 'project2' folder thus still has 'project1' as its name.
* Go back to Eclipse.
* File -> Import -> Projects from Folder or Archive. Select the folder that contains the 'project1' and `project2' directories.
* Observe how 'project1' and not be imported, as 'Folder already imported as project' is indicated in the 'Import as' column.
* Observe how 'project2' can be imported, and the 'Import as' column indicates 'Eclipse project'.
* Select only the 'project2' project to be imported, and click 'Finish'.
* Observe how nothing has happened. No new projects are present in the Package Explorer. Project 'project1' is still there, and still comes from the 'project1' directory. There are no error dialogs. The are no new entries in the 'Error Log' view.

Basically, the project from the 'project2' directory can't actually be imported, as its name conflicts with the name of the already imported project from the 'project1' directory. However, the import dialog doesn't seem to know this. It allows importing it. But then it doesn't actually import it. It silently ignores the issue and does nothing. The user is not informed in any way, whatsoever. I can even repeat the steps and import it over and over again, without any message why it is not importing the project.

This issue is somewhat different from Bug 218024, where nested projects are involved, while this issue is not concerned with nesting projects. It is also not clear in that issue what import wizard is used (there are multiple ones).

I also found Bug 526490, which was fixed. But given that I still have this problem, that must either be a slightly different use case, or it was not fixed correctly.
Comment 1 Wim Jongman CLA 2022-03-13 09:08:39 EDT
Dennis, can you take a stab at solving this?
Comment 2 Rolf Theunissen CLA 2022-03-13 11:46:41 EDT
The statement that the project cannot be imported is not completely true. As the project is located in the workspace location, the directory name is by definition the project name. For the "Import exiting projects into Workspace" wizard this is implemented in Bug 143757.

The "Projects from Folder or Archive" (SmartImport) was introduced with Bug 472614, so Bug 218024 probably refers to the "Import exiting projects into Workspace" wizard and is unrelated.

In the SmartImportJob exceptions are caught, but not reported to the user. This was never fixed before. 

Bug 526490 (attempted) fixed some constraint in the UI, so that no illegal selection could be made. In fact, this change is not consistent with the logic in SmartImport as it 1) assumes that the directory is a project directory and 2) only considers the directory name and not the project name in the .project file. 

In this reported case, the directory name is allowed but the name from the .project file is not allowed. This also fails when the project is not located in the workspace.
Comment 3 Rolf Theunissen CLA 2022-03-13 11:47:57 EDT
(In reply to Wim Jongman from comment #1)
> Dennis, can you take a stab at solving this?

I am already looking into this, but (once again) it is not as small as expected. At least I have partial fixes ready.