Community
Participate
Working Groups
I have all my projects in various working sets in the package explorer, and set the view presentation to have those working sets as top level elements. Focussing the package explorer used to work fine, but something changed lately it seems, as now I am just getting the "other projects" root node displayed, no matter how much context the active task has. Switching the top-level element to projects populates the view as expected.
Maybe me accidentally having some CDT plugins I am bootstrapping with is an issue. While playing around (focussing/unfocussing and changing top level element) I eventually got it appear correctly with working sets as top level, but then had this error in the log: C Model Exception: C Model Status [Element does not exist.] at org.eclipse.cdt.internal.core.model.PathEntryManager.getRawPathEntries(PathEntryManager.java:646) at org.eclipse.cdt.internal.core.model.PathEntryManager.getResolvedPathEntries(PathEntryManager.java:552) at org.eclipse.cdt.internal.core.model.PathEntryManager.getResolvedPathEntries(PathEntryManager.java:536) at org.eclipse.cdt.internal.core.model.PathEntryManager.getResolvedPathEntries(PathEntryManager.java:522) at org.eclipse.cdt.internal.core.model.PathEntryManager.getResolveInfo(PathEntryManager.java:449) at org.eclipse.cdt.internal.core.settings.model.PathEntryConfigurationDataProvider.createData(PathEntryConfigurationDataProvider.java:304) at org.eclipse.cdt.internal.core.settings.model.PathEntryConfigurationDataProvider.createData(PathEntryConfigurationDataProvider.java:274) at org.eclipse.cdt.internal.core.settings.model.PathEntryConfigurationDataProvider.loadConfiguration(PathEntryConfigurationDataProvider.java:363) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.loadData(CProjectDescriptionManager.java:1664) at org.eclipse.cdt.internal.core.settings.model.CConfigurationDescriptionCache.loadData(CConfigurationDescriptionCache.java:95) at org.eclipse.cdt.internal.core.settings.model.CProjectDescription.loadDatas(CProjectDescription.java:194) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.loadProjectDescription(CProjectDescriptionManager.java:1042) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescription(CProjectDescriptionManager.java:547) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescription(CProjectDescriptionManager.java:523) at org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.getProjectDescription(CProjectDescriptionManager.java:515) at org.eclipse.cdt.internal.core.model.CProject.computeSourceRoots(CProject.java:605) at org.eclipse.cdt.internal.core.model.CProject.computeChildren(CProject.java:626) at org.eclipse.cdt.internal.core.model.CProject.buildStructure(CProject.java:590) at org.eclipse.cdt.internal.core.model.Openable.generateInfos(Openable.java:269) at org.eclipse.cdt.internal.core.model.CElement.openWhenClosed(CElement.java:424) at org.eclipse.cdt.internal.core.model.CElement.getElementInfo(CElement.java:303) at org.eclipse.cdt.internal.core.model.CElement.getElementInfo(CElement.java:293) at org.eclipse.cdt.internal.core.model.Parent.getChildren(Parent.java:55) at org.eclipse.cdt.internal.core.model.CProject.getSourceRoots(CProject.java:482) at org.eclipse.cdt.internal.core.model.CModelManager.create(CModelManager.java:312) at org.eclipse.cdt.core.model.CoreModel.create(CoreModel.java:117) at org.eclipse.cdt.internal.ui.ResourceAdapterFactory.getAdapter(ResourceAdapterFactory.java:48) at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:295) at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66) at org.eclipse.mylyn.internal.cdt.ui.CDTStructureBridge.acceptsObject(CDTStructureBridge.java:174) at org.eclipse.mylyn.internal.context.core.ContextCorePlugin.getStructureBridge(ContextCorePlugin.java:255) at org.eclipse.mylyn.context.core.ContextCore.getStructureBridge(ContextCore.java:41) at org.eclipse.mylyn.context.ui.InterestFilter.select(InterestFilter.java:66) at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.isFiltered(ProblemTreeViewer.java:310) at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.isFiltered(PackageExplorerPart.java:275) at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.filter(ProblemTreeViewer.java:274) at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.getFilteredChildren(ProblemTreeViewer.java:263) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:601) at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:801) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:778) at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:644) at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1714) at org.eclipse.jface.viewers.AbstractTreeViewer.internalExpandToLevel(AbstractTreeViewer.java:1724) at org.eclipse.jface.viewers.AbstractTreeViewer.expandToLevel(AbstractTreeViewer.java:1056) at org.eclipse.jface.viewers.AbstractTreeViewer.expandToLevel(AbstractTreeViewer.java:1037) at org.eclipse.jface.viewers.AbstractTreeViewer.expandAll(AbstractTreeViewer.java:1026) at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager.updateExpansionState(FocusedViewerManager.java:383) at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager.access$1(FocusedViewerManager.java:367) at org.eclipse.mylyn.internal.context.ui.FocusedViewerManager$FocusedViewerDelayedRefreshJob.doRefresh(FocusedViewerManager.java:112) at org.eclipse.mylyn.internal.provisional.commons.ui.DelayedRefreshJob.runInUIThread(DelayedRefreshJob.java:96) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
It seems to work after removing the CDT plugins. Shawn, please close if you feel like it (you wanted to take a look at the stack trace). I will reopen if I see this again.
Actually I am still seeing it. Came back from lunch break and realized it. Wonder what triggered it though, have not (de)activated a task in the meantime.
*** Bug 353721 has been marked as a duplicate of this bug. ***
Currently it is not deterministic which bridge will handle filtering of working sets. If canFilter() is invoked on a bridge that doesn't find any interesting elements contained in the working set the working set will end up being filtered even though another bridge may have interesting children in the working set. For example, if the CDT bridge handles filtering of a working set that only has Java projects the result maybe an empty package explorer even though some of the Java projects maybe interesting. The reason is that most bridges invoke getHandleIdentifier() on their own bridge in in canFilter() instead of delegating to the framework. The fix for bug 389102 made this problem occur more frequently since working set filtering in the CDT bridge didn't work as expected previously causing working sets to be shown rather than filtered as intended. Sam, Shawn, instead of copying the working set filtering code to each bridge it seems that there should be something in the framework to manage that. I have scheduled this for the next maintenance release since it's very visible impact that breaks focusing for views that show working sets as top-level elements such as the Package Explorer.
Thanks for the write-up, Steffen. Work was piling up a bit after ECE, so I didn't get around to it before. I've submitted a patch to Gerrit at https://git.eclipse.org/r/#/c/8406/ that solved the issue for me. Patch set 1 just does the minimal thing by delegating to the framework, while patch set 2 actually moves the WorkingSet code to the ResourceStructureBridge.
Created attachment 222962 [details] mylyn/context/zip
It still seems like a bug to me that the framework can be broken by a bad structure bridge. Would it make sense to consult all bridges and filter only if none of them find interesting elements? Maybe this should be done only for certain elements like working sets.
I don't have a good sense to what extend that is a problem. Sam, please open a separate bug report if you have thoughts how to improve the framework. It's out of scope of getting this bug fix into the maintenance stream. I have merged the change into master and the e_3_8_m_3_8_x branch. Thanks a lot for your contribution, Carsten!
I've opened 393378: consult all applicable structure bridges when filtering https://bugs.eclipse.org/bugs/show_bug.cgi?id=393378
Verified with 3.8.3.v20130107-0100.
*** Bug 398482 has been marked as a duplicate of this bug. ***
