Bugzilla – Full Text Bug Listing
| Summary: | [resources] Cannot open closed projects without .project | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Philipe Mulet <philippe_mulet> |
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Philipe Mulet
This is expected behaviour. We don't automatically reconcile added or deleted projects. If we did that we'd have to throw away all metadata for that missing project, which would be too drastic. Maybe the user accidently moved their project elsewhere, or their project is on a drive that is not currently accessible. The current behaviour gives the user an opportunity to "find" and bring back their project, and then re-open it in Eclipse. If you really want to get rid of it, the user should be able to delete that closed project from eclipse. As John mentions, we do not want to agressively delete projects since they could just be unavailable at the time (network drive down, etc) and that would result in loss of data for the user. Closing. I understand this argument, but only for external projects... Anyway, the current behavior makes some sense still. Actually, maybe a bonus marker on the project might be helpful ? Because when opening the offending project, you get into trouble still. - manually delete a .project file on disk - open Eclipse - the corresponding Project is closed since the .project does not exist - you are unable to open the project Is this really what we want? Note: if you have a closed 1.0 project it will open since it reads the .prj from the metadata area. This is the intended behaviour. Allowing a user to open this project isn't doing them any favours, since it will be missing its natures and build spec, and there is no easy way to add these things back except by manually hacking the .project file. This is documented in: org.eclipse.core.resources/doc/project_description_file.html I agree, but then the error should suggest that the project resource is missing... not one of its contained file. Anyway, checked again on 20020521 with following steps: - create Java project: CCC - expand it: it contains .project and .classpath - switch to file system: delete folder CCC - perform a refresh in the navigator view --> error (missing .project) - observe that the project is NOT closed, and that if missing .project, it still pretends having a .classpath file (lie). I would have expected this project to get closed in a consistent way with restarting such a workspace. Closing old bug. The current behaviour is fine. |