Community
Participate
Working Groups
From platform-ui mailing list: I think I also came upon a bug(?) in the task list and/or the JDT extension to it. The filtering function uses DEPTH_INFINITE to find all tasks for a resource and its children. For Java packages, this means all packages "under the hierarchy" are included in the marker search as well. This is not the right thing since there isn't a hierarchical relationship between packages in Java. It comes about only because a folder hierarchy is used to represent packages. You can test this out, for instance, by setting up Apache log4j as an Eclipse project. After you make a breaking change in org.apache.log4j.Category class, you can see all the errors in all org.apache.log4j.* packages when you select org.apache.log4j package. It seems there are two alternatives to fix this as far as I can see. Provide another resource filtering option that will use Iresource.DEPTH_ONE to search for markers, or extend the ITaskListResourceAdapter interface to ask the adapter the maximum depth a marker search for the given resource can go.
Moving to JDT for comment.
Given the current support the JDT cannot help to improve this. JDT gets only involved when mapping the selected Java element in the packages view to a resource, the recursive travsal is done by the Task list. To fix this the JDT would also need a way to control the traversal. One option would be a custom adapter interface with methods to retrieve the makers for children. Moving back to Platform UI
I recently proposed having an IMarkerProvider adapter on the selected element which had a method IMarker[] getMarkers(boolean includeChildren). This would address this case, but would not support more general filters (such as the one Cagatay added for all markers in project). One option would be to ask the filter first, then it would get the markers from the appropriate place. For example, - the default filter (all tasks in workspace) would just query the workspace root for all markers with depth infinity - the "On Selected Resource" filter would check for an IMarkerProvider and pass false for includeChildren. It would fall back on the current IResource adapter approach if no IMarkerProvider. - the "On Selected Resource Including Children" filter would be the same as previous but with includeChildren==true. - the "On Same Project" filter would determine the current project of the element (also using the IResource adapter approach) Would also need isAffectedBy(IMarkerDelta). Also, it would help to know the topmost resource the marker provider cares about, as an optimization (could ignore all other marker deltas if only looking at those for a single file, without having to test each marker delta).
I'm still in favor of the IMarkerProvider proposal. It is a step forward to remove an IResource dependency in the UI. It would be straightforward for JDT to leverage the new support. There already is an ITaskListResourceAdapter could this additional hierarchy traversal protocol and isAffected be folded into this interface?
An IMarkerProvider (or ITaskListMarkerProvider) would replace ITaskListResourceAdapter, which is still too resource-centric. Still need to sort out how to divide filtering responsibilities for the other items in the filters dialog (marker types, attribute filters).
Bug 25274 and bug 32293 address the logical-to-physical problem for java packages. The ITaskListMarkerProvider approach would still be useful to handle elements that are at a finer granularity than the file, e.g. Java methods.
*** Bug 31784 has been marked as a duplicate of this bug. ***
*** Bug 62229 has been marked as a duplicate of this bug. ***
I think this is no longer an issue.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
