Community
Participate
Working Groups
Created attachment 125810 [details] Traceback when changing the working set. Build ID: I20090202-1535 Steps To Reproduce: With Eclipse 3.5M5, install Pydev, open a pydev package explorer and select/deselect a working set. Note that the exception happens in Pydev, but the bug is in th CNF (Common Navigator Framework) More information: 1. I'm in PydevPackageExplorer -- which is based on the CNF (Common Navigator Framework) 2. I set a selection in the tree viewer and it ends up with a stack trace (attached) or 2. A working set is selected/deselected I'm not sure why this is happening now (it works without problems on 3.4.1), but the problem seems to be that org.eclipse.ui.internal.navigator.resources.actions.WorkingSetActionProvider (which apparently is responsible for adding the working set actions) thinks it's dealing with the ProjectExplorer and not with some other navigator that uses the CNF.
Created attachment 125811 [details] Traceback when setting the selection
I just saw that in the Project explorer when the Working set changes, it's updated with the name of the working set (this seems to be a new feature), so, it probably was introduced at that time. Those methods (setWorkingSetLabel / getWorkingSetLabel) should probably be in the CommonNavigator class and that action should cast to CommonNavigator -- which is something the CNF expects.
Yes, this was changed in 3.5M5, some of the working set support is now dependent on the use of the ProjectExplorer class (which is a subclass of CommonNavigator). Clearly something needs to be done, but I need to look into it more to see the direction to take. The solution might be to require clients to subclass ProjectExplorer if they are going to use the working set support. This is an acceptable API change because prior to 3.5 we did not support subclassing the CommonNavigator class at all. However I will look into the possibility of moving some of the support up to CommonNavigator so even though clients that have illegally subclassed CommonNavigator will continue to work.
(In reply to comment #2) > I just saw that in the Project explorer when the Working set changes, it's > updated with the name of the working set (this seems to be a new feature), so, > it probably was introduced at that time. > > Those methods (setWorkingSetLabel / getWorkingSetLabel) should probably be in > the CommonNavigator class and that action should cast to CommonNavigator -- > which is something the CNF expects. > Seems reasonable. When I get some time I will check this out more.
*** Bug 265320 has been marked as a duplicate of this bug. ***
Released to HEAD N20090305-2000, 35M6
*** Bug 268248 has been marked as a duplicate of this bug. ***
I've just gotten version: Build id: I20090313-0100 and the bug still appears to be there. I took a look at http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ui.navigator.resources/src/org/eclipse/ui/internal/navigator/resources/actions/WorkingSetActionProvider.java?view=markup... It seems that even though you can do viewer.getCommonNavigator().setWorkingSetLabel, there are still some references that try to cast to the ProjectExplorer before doing so. Namely lines: 155, 158, 160, 163 and 165 (just removing the ProjectExplorer import shoud signal those).
Any chance those casts can be removed for 3.5M7? Thanks.
(In reply to comment #9) > Any chance those casts can be removed for 3.5M7? I will have a look at this soon, and if it's a problem it will be fixed for M7.
Created attachment 130145 [details] Patch removing those casts Just added a patch against the current head removing those casts. Best Regards, Fabio
Sorry about that, released the removal of the casts to HEAD, N20090327-2000, 35M7 I don't have tests for this, so if you can take the nightly and verify this bug I would appreciate it.
I updated to HEAD here (instead of getting the nightly) and it worked for me (marking as VERIFIED). Thanks, Fabio
