Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333437

Summary: PSF export of closed project: project cannot be imported and is not added to working set
Product: [Eclipse Project] Platform Reporter: Martin Oberhuber <mober.at+eclipse>
Component: TeamAssignee: Platform Team Inbox <platform-team-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, markus.kell.r, remy.suen, tomasz.zarna
Version: 3.6.1   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard: stalebug
Attachments:
Description Flags
Screenshot showing error for delete
none
Sample PSF with a broken reference none

Description Martin Oberhuber CLA 2011-01-03 14:32:33 EST
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).
Comment 1 Martin Oberhuber CLA 2011-01-03 14:33:44 EST
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.
Comment 2 Martin Oberhuber CLA 2011-01-03 14:35:35 EST
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.
Comment 3 Martin Oberhuber CLA 2011-01-05 07:03:04 EST
*** Bug 300368 has been marked as a duplicate of this bug. ***
Comment 4 Martin Oberhuber CLA 2011-01-05 08:04:30 EST
Bug 333406 also talks about the need to allow deleting (unregistering) a project from the Worksepace even in case of errors.
Comment 5 Markus Keller CLA 2011-01-07 10:10:03 EST
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).
Comment 6 Martin Oberhuber CLA 2011-01-10 06:19:25 EST
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.
Comment 7 Markus Keller CLA 2013-11-29 11:17:32 EST
Updated bug summary to current state (comment 5 1)
Comment 8 Eclipse Genie CLA 2020-05-29 03:25:33 EDT
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.