Community
Participate
Working Groups
In large projects, many times there are individual Java files, entire packages and sometimes even entire branches of the source tree that will not compile for one reason or the other. From a particular developer's point of view that may or may not be a problem. However, the (potentially) large numbers of errors that the developer does not care about still clutters up the errors in the task view that he/she really cares about. It would be nice to have a capability to either mark individual Java file(s), or packages or parts of the source-tree to mean "do not compile and/or report errors". Alternatively, filtering of the task view could be enhanced to ignore errors from multiple unrelated Java file (s), or packages (currently, the choice is limited to either the selected resource or ALL errors from the selected project). In a discussion about this on the Eclipse newsgroup, it was mentioned that the source could be partitioned in a different way to allow current Exlipse functionality to do the filtering. But, in cases where the source tree already exists in a large (open source, say) project, such reorganization is often not possible. Another workaround mentioned was to root each part of the source tree individually, which might work in certain cases, but quickly becomes tedious as the number of branches of the src tree increases.
Working sets will address this, but are not yet supported in the TaskList. Moving to Platform-UI
Would be nice to have this for 2.0.
*** Bug 12282 has been marked as a duplicate of this bug. ***
Added working set support to the task view filter dialog. If selected only markers that are in a working set resource will be displayed in the task list.
Hi! I just tested this using the F1 build. It is better in the sense that I can filter based on a working set, and only errors/warnings from that working set are being shown in the task view. But if I edit the working set to uncheck one or more particular packages in the source hierarchy (those that have errors that I can neglect), the errors are still showing up in the Task view. Shash
The problem is a combination of the fact that the org.eclipse.ui.views.tasklist.TasksFilter is resource based and the way working set elements are collected in the Resource- and JavaWorkingSetPage. Given a structure A a A.java a.b AB.java The TasksFilter assumes that if folder a is checked and included in a working set all of a's children should be displayed. This works with a resource working set because a is only checked if all its children are checked in the ResourceWorkingSetPage. Otherwise only the checked children are placed in the working set. I.e., if b below a is not checked a is grayed out and A.java is added instead of a. This does not work with Java working sets because package a may be included in the working set but a.b may not. a is checked and a.b is not but the working set contains a instead of a/A.java. There are two possible solutions: 1) Change TasksFilter.isEnclosed to test the path of a resource for equality with a working set element. This means that all leaf elements of folders have to be included in a working set. This would change the semantics of the ResourceWorkingSetPage since currently, checking a folder means the actual folder is placed in the working set vs. all its children. New children are automatically considered to be included in the working set. It would also degrade performance since working sets would contain a potentially huge number of leaf elements vs. a single folder or project. Filtering in the resource navigator would be slower. 2) Change JavaWorkingSetPage to mimic the ResourceWorkingSetPage. Leave the UI the way it is but explicitly include children of packages in the working set instead of the packages themselves if not all package fragments are checked (e.g, a is but a.b is not). This would mimic the graying out of a in the ResourceWorkingSetPage. There is another option which I don't think we can/should seriously consider. That would be to allow for a custom working set filter in the org.eclipse.ui.workingSet extension point. I hacked the JavaWorkingSetPage to simply test if a checked element is a package fragment. This is a lesss optimal but quick version of solution 2). It would cause leaf elements to be included even if all packages are selected. Moving to JDT UI for comment/fix. See the changed JavaWorkingSetPage.findCheckedElements: Object[] children= fTreeContentProvider.getChildren(parent); for (int i= 0; i < children.length; i++) { if (fTree.getGrayed(children[i])) findCheckedElements(checkedResources, children[i]); else if (fTree.getChecked(children[i])) { // don't add package fragments directly if ((children[i] instanceof PackageFragment)) findCheckedElements(checkedResources, children[i]); else checkedResources.add(children[i]); } }
Shash, Please confirm that the scenario I describe above matches your scenario. I.e., you deselect package a.b, keep package a selected and still see errors for a.b.
Yes, I confirm this is exactly what is happening. I have (with the project source directory being WEB-INF/src): WEB-INF/ src/ com/ jcorporate/ expresso/ X.java core/ Y.java security/ Z.java strongencryption/ A.java B.java weakencryption/ C.java D.java In this enviornment, because I didn't install the required JAR(s), strongencryption/*.java all have compilation errors. So, I unchecked the com.jcorporate.expresso.core.security.strongencryption. But those errors still show up in the task view, until I uncheck the following as well: com.jcorporate.expresso.core.security com.jcorporate.expresso.core com.jcorporate.expresso com.jcorporate WEB-INF/src
This problem is real so that we should tolerate a minor hack that get's us there. Should investigate for F1.
Thinking of it again. Option 2) isn't an option. The main reason why we wanted to have support for Java specific working set is that you can define working sets with the Java semantics. This is already leveraged for Java specific searching. We do not want to loose this functionality. The original idea for handling this problem was to leverage the IWorkbenchAdapter. Did you ever investigate more into this path? There were some issues but the path looked promising to me. This was Nick's latest proposal: - The working set has the shape as proposed in 2, and contains IJavaElements, e.g. { package fragment: java.lang } - This is mapped to the corresponding resource using getAdapter (IResource.class): IAdaptable item = workingSet.getItems()[0]; IResource resource = (IResource) item.getAdapter(IResource.class); // e.g. resource is folder /JCL/src/java/lang - We get the children using IWorkbenchAdapter on the working set item (not the resource): IWorkbenchAdapter a = (IWorbenchAdapter) item.getAdapter (IWorkbenchAdapter.class); Object[] children = a.getChildren(item); // the adapter doesn't wrap the item, so we need to pass it back // e.g. children now contains CU: Object.java, etc., but not package fragment: java.lang.reflect for (int i = ...) { IResource childResource = (IResource) children[i].getAdapter (IResource.class); // e.g. children[i] is the CU for Object.java, childResource is the corresponding IFile }
Reassigning to Chris who is looking at Task view issues, since Knut is away.
Working sets address the original complaint. We still need to address the mapping from packages to resources, but this will have to wait until after 2.0.
Post 2.0.
Reopen to investigate
Closing bug since original feature has been implemented. Java working set problem wrt. packages is a general issue that does not just apply to the tasks view. Bug 25274 has been opened for this.
