Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1.File -> Import... -> Team -> Team Project Set and select the .psf 2.Check "Add the imported team project set to a working set" 3.Click Browse and type in the name of a working set that does not exist 4.Click OK and Finish 5.Select Configure Working Sets from the Project Explorer 6.Note that the working set is not in the list 7.Click New... and type in the name of the fake working set 8.Note the error: A working set with that name already exists. More information: I think that the ability to import a project set as a working set makes a lot of sense. The wizard should either not allow the user to create a working set or create the new working set properly. Obviously, the latter would be preffered.
The project explorer seems to be broken when grouping by workings sets. I also didn't understand how this works.
I've followed the steps from comment 0, but everything looks fine to me. After selecting "Select Working Set..." ( I belive this is what you meant by "Configure Working Sets") I am able to see the newly added working set in the list. It works fine in both Project and Package Explorers. The only problem I've observed is that in the Project Explorer the "Edit Active Working Set" doesn't go on for the newly created set. Lee, have you observed any errors while importing the project set?
Interesting...the "Select Working Sets..." option shows the new working set just as you mentioned. The problem I reported still exists, I just made a mistake in the steps to reproduce. You will find the "Configure Working Sets..." option in the Package Explorer menu, not the Project Explorer menu. This is the view in which the new working set is not visible. As Martin points out, this problem also is seen when you select Top Level Elements -> Working Sets from the Package Explorer.
The Java package explorer only accepts resource and Java working sets as top level nodes. I have no idea what kind of working set team creates here.
Oh, now I can see it too. I need to set "Working Set" as "Top level elements" in the Package Explorer. This is when the "Configure Working Set" entry shows up. Martin: It's a resource working set which is being created. At least, this is how the icon looks like.
I can manually create a Resource working set and it shows up in the package explorer. So it seems that the one created by team is somehow different.
workingSet.getID returns null. The resource working sets I created through the wizard contain 'org.eclipse.ui.resourceWorkingSetPage' The id is required for the test 'WorkingSet.isSelfUpdating()'.
Team uses the IWorkingSetManager[1] to create a working set when asked during a Project Set Import. It seems that the working set returned from the createWorkingSet method[2] is not what the "Configure Working Set" is expecting. It doesn't look like a team bug anymore to me. [1] org.eclipse.ui.IWorkingSetManager#createWorkingSet(String, IAdaptable[]) and org.eclipse.ui.internal.AbstractWorkingSetManager [2] org.eclipse.team.internal.ui.wizards.ImportProjectSetOperation line 72
I seem to recall that Markus gave us a patch at some point that allowed the user to create any type of working set they desired when importing. Perhaps that was for the CVS Import Wizard? I also seem to recall that there was some support added to the Platform to improvie this type of working set creation. We should investigate this as well (I seem to recall that Kim logged a bug against Team or CVS to adopt the new support).
The bug logged by Kim - bug 201597.
The bug with the patch by Markus - bug 167595.
Created attachment 90166 [details] Patch Patch that adds the new controls outline for working sets (see bug 199904). This simplifies the code of the ImportProjectSetMainPage class including it's updateEnablement method. However, there is still one minor issue related to the enablement but I will report a separate bug for it. This is also a partial fix for bug 201597.
Created attachment 90167 [details] mylyn/context/zip
Released to HEAD.
Verified in I20080304-1113.
