Community
Participate
Working Groups
Created attachment 185968 [details] Screenshot showing error for delete Build ID: Eclipse SDK 3.7m4 (also reproduced with 3.6.1) When exporting a Team Project Set with Working Sets, and one of the working sets includes a project that's closed at the time of export, the PSF includes a broken reference to that project. Importing this PSF displays the broken reference in the Workspace. The broken reference cannot be opened or deleted, which is confusing. Steps to reproduce: 1. Have some projects CVS controlled. 2. Create a working set holding the projects. 3. Close one of the projects 4. Export Team Project set, including the working set. 5. Import the Team Project Set into an empty workspace. 6. In Project Explorer or Package Explorer, select "Toplevel Elements: Working Sets". --> Under the working set node, there is a closed project icon for the broken reference that was imported from the PSF. --> That project reference cannot be opened or deleted from the workspace (See attached screenshot), which is confusing for end users This is a funny problem since each of the steps makes sense by itself, but the end result is confusing. One could argue that the closed project shouldn't be exported as part of the working set in the first place; but in some sense, the placeholder makes sense as a reminder that the original working set contained more than what happened to be exported. I think an ideal solution would export a proper team reference for the closed project along with a hint that it should be closed when importing the team reference. Likely the simplest solution is not exporting references for closed projects. Another option would be allowing to export/import the broken reference, but allowing to delete it (eg by making it adaptable to something that is deletable).
Created attachment 185969 [details] Sample PSF with a broken reference Attached sample PSF includes a broken reference to project "org.eclipse.rse.ui.capabilities" which exists in the workingset, but not as a team reference.
Thinking again, I've been arguing on multiple other occasions that a "Delete from Workspace" should always be possible, even if a fatal error occurs. Such a fix would be good enough IMO.
*** Bug 300368 has been marked as a duplicate of this bug. ***
Bug 333406 also talks about the need to allow deleting (unregistering) a project from the Worksepace even in case of errors.
I've fixed the bad project reference in the Resource Working Set (bug 300368). This fixes the problem on the import side, but still leaves a problem on the export side with a few possible solutions: 1) Leave it as is, i.e. export closed and unshared projects. On import, the unshared projects are added to the working set iff they already exist in the workspace (otherwise, they are simply removed from the working set). 2) Add special code for closed projects that still exports them with repository information. On import, the closed projects are imported from the repository, but they are not closed any more. 3) Add special code for closed projects that still exports them with repository information, but also add a flag to <project> reference that marks the project as closed. On import, everything will look like in the original workspace (except for unshared projects, which will simply not get imported).
As an end user, option (3) is what I expect, ie faithfully reproduce the original working set along with closed/open information. A workaround that I could live with is a notification dialog on export: "Working sets contain closed projects. These will not be exported to the team project set [OK | CANCEL]". Then I'm notified on export that if I want to team-share my closed projects too, I need to open them first. Auto-opening a project on import that was closed before may have negative effects. In my case, the closed project was one that contained Capability definitions. As a result, when the project is open while running a debuggee, some expected UI elements are missing. Therefore it makes sense to have the project closed by default when importing the team project set.
Updated bug summary to current state (comment 5 1)
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
