Community
Participate
Working Groups
Build ID: 3.3 Steps To Reproduce: Goto Eclipse Unit Tests. class - org.eclipse.ui.tests.api.IWorkingSetTest. Test - "testSetName()" And change code of testSetName() to the following: /* added lines has comments */ public void testSetName() throws Throwable { /* get workingSetManager */ IWorkingSetManager workingSetManager = fWorkbench.getWorkingSetManager(); /* check that initially workingSetManager contains "fWorkingSet" */ assertTrue(ArrayUtil.equals( new IWorkingSet[] { fWorkingSet }, workingSetManager.getWorkingSets())); /* remove "fWorkingSet" from working set manager */ workingSetManager.removeWorkingSet(fWorkingSet); /* check that "fWorkingSet" was removed */ assertTrue(ArrayUtil.equals(new IWorkingSet[] {}, workingSetManager.getWorkingSets())); /* restore state */ workingSetManager.addWorkingSet(fWorkingSet); /* original code of "testSetName" is started */ boolean exceptionThrown = false; try { fWorkingSet.setName(null); } catch (RuntimeException exception) { exceptionThrown = true; } assertTrue(exceptionThrown); fWorkingSet.setName(WORKING_SET_NAME_2); assertEquals(WORKING_SET_NAME_2, fWorkingSet.getName()); fWorkingSet.setName(""); assertEquals("", fWorkingSet.getName()); fWorkingSet.setName(" "); assertEquals(" ", fWorkingSet.getName()); /* original code of "testSetName" is ended */ /* check that workingSetManager contains "fWorkingSet"; this line should pass correctly */ assertTrue(ArrayUtil.equals( new IWorkingSet[] { fWorkingSet }, workingSetManager.getWorkingSets())); /* remove "fWorkingSet" from working set manager */ workingSetManager.removeWorkingSet(fWorkingSet); /* check that "fWorkingSet" was removed; BUT! Here you will get assert, because of after renaiming WorkingSet CAN'T be removed */ assertTrue(ArrayUtil.equals(new IWorkingSet[] {}, workingSetManager.getWorkingSets())); /* restore state */ workingSetManager.addWorkingSet(fWorkingSet); } I've got failures of the modified unit test on BEA 1.5 and SUN 1.6. More information: WorkingSetManager stores all working sets in java.util.SortedSet (java.util.TreeSet) using WorkingSetComparator for ordering. WorkingSetComparator determine order of WorkingSet using labels and names of working sets. If WorkingSet.setName() (or setLabel()) methods are called and name (or label) was changed then this actions change ordering of working sets. If at this moment working set was stored in TreeSet - the full ordering logic of TreeSet is broken. Possible solutions: 1. implements comparator which based on unchangable properties of WS. 2. Complicate logic of setName( and setLabel): - remove WS from all TreeSets where it is stored; - only after that it is safe to change name/label; - add WS back to TreeSets where it was.
Hitesh, you're looking at Working Set bugs right? Can you have a look at this on please?
Created attachment 128358 [details] Patch v1 This patch is along the lines of the first suggestion. I have added a new field to workingsets,'uniqueId'; this is a workspace-wide unique id for a workingset. Currently we do not have a strictly immutable property in a workingset, and also, this may come in handy for a few other bug fixes :). Eric , could you please review the patch.Do you remember the timeStamp thing, it is the same, only here I call it uniqueId keeping in mind that this maybe a good candidate for API. The patch also contains some addtional tests for workingsets.
Adding Boris for review...
Patch looks good. A minor nit: org.eclipse.ui.tests.api.IWorkingSetManagerTest.testRemoveWorkingSetAfterRename - you restore the state before reporting a test failure, which is good. Instead of 'assertTrue(false)' I would recommend using 'fail("expected that fWorkingSet has been removed")'. This will ensure that a meaningful message is generated should this fail during a test run.
Created attachment 132988 [details] Hitesh's patch with the 'assertTrue(false)' changed as per Boris' comment
Committed in >20090423. Applied the patch in the above comment.
Marking as FIXED, nice work.
Created attachment 133011 [details] Patch to fix regressions in the API tests The IWorkbenchTest.testGetWorkingSetManager() was adding a WorkingSet called 'ws1' but never removing it. This was causing subsequent tests that tried to add 'ws1' to fail due to the change in the 'assertTrue' in AggregateWorkingSetManager.addWorkingSet. This patch simply removes 'ws1' after the test completes, allowing the other tests to run correctly.
Committed in >20090423. Patched the test using the patch. Hitesh, now I'm a bit confused. If we've introduced the 'uniqueId' why do we still need to check the name when adding a working set?
Eric, the workingsetmanager can contain workingsets that are unique by name within its scope (See API doc).The uniqueid indirectly addresses related set of problems.
*** Bug 262891 has been marked as a duplicate of this bug. ***
Thanks Hitesh, something to consider for 3.6...with the new 'uniqueId' code would it be possible to remove the name restriction? My understanding is that part of the issue was that we were using the name as the child IMemento's id but we can fix that by using the new field, are there other issues that you can see?
(In reply to comment #12) > Thanks Hitesh, something to consider for 3.6...with the new 'uniqueId' code > would it be possible to remove the name restriction? My understanding is that > part of the issue was that we were using the name as the child IMemento's id > but we can fix that by using the new field, are there other issues that you can > see? > We should be able to take care of the save/restore problem with this new field without any trouble.Will post a patch.
Verified in I20090426-2000.
Beauty, thanks.