Bugzilla – Full Text Bug Listing
| Summary: | [LinkedResources] Dropping folder from OS onto project should be absolute by default | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | IDE | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Serge Beauchamp <serge> |
| Severity: | normal | ||
| Priority: | P3 | CC: | Szymon.Brandys |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
First, extensive changes have been made to Bug 302441 so that the default selection is not present anymore. Instead, the most appropriate variable based on the items dropped is selected as default. In your case, if ECLIPSE_HOME is selected, that will mean that a files and folders children of the ECLIPSE_HOME directory are dragged and dropped, i.e. something off the eclipse/ folder. Then, regarding generating absolute location links by default, I strongly disagree with this. This has been discussed already in bug 302152. Quoting from that bugs comments: "Well, let me put things in perspective. First, from a user's point of view, a project that contains linked resources with absolute paths is a broken project, that is non-portable. The user can't put it as-in in a source control repository, he has to fix it (and first and foremost, be aware that the project needs to be fixed). For the overwhelming majority of users, a project that is non-portable (that works only on a given computer, with a given set of hard-coded paths) is a major problem. This was one significant reason why linked resources weren't used before, and a obstacle that the flexible resource effort aim at overcoming. Now, from first hand experience with our own customers using our IDE, and using the Eclipse CDT toots, the lessons that we learn, is that in order for the users to have portable projects, the following principles must be followed: 1) The IDE operations don't create non-portable projects by default (creates projects, files, linked resources, copy, move, etc...), so non-portable projects are not the result of an operation other than the explicit creation of a non-portable setting. 2) 'Cleaning-up' a project that is portable is quick and easy. The solution for 1), is that all operations (import files, copy, move, etc..) by default maintain the portability of the project. The solution for 2), is the new linked resource editor (the second tab of the linked resource property page)." Creating linked resources to default as absolute paths is wrong because: "1) I can't conceive of any significant amount of users that desire to have absolute path linked resource locations for its own sake in the project, apart from a temporary state. 2) This makes the project non-portable without the user being aware of it, so he can commit the project to a SVC, and break the build for someone else without being aware of it. 3) if the core.resource algorithm picked a variable the user didn't want, it's easy for the user to correct it in the linked resource editor (and especially easy converting the resources to absolute paths)." Since you raise at least 2 different issues, that have been both raised and addressed in two different bugs (one close, and the other pending), I'll flag this bug as a duplicate. *** This bug has been marked as a duplicate of bug 302152 *** |
I20100209-0800. Dropping a folder from OS onto project should use absolute path by default. Currently it is relative to {$ECLIPSE_HOME}. 1. start new workspace 2. create a project 3. from an OS file explorer drag a folder onto the project 4. choose 'Recreate ... with virtual ...' (leave automatic) 5. click 'OK' ==> in the project's 'Linked Resources' properties page you'll see that the path is relative to newly generate 'eclipse' variable (see bug 302152) instead of using absolute path. As already stated in bug 30144 comment 57, we should get rid of automatic/default anyway.