Community
Participate
Working Groups
Build Identifier: M20100909-0800 (Fedora eclipse-3.6.1-6.2.fc14.x86_64) When a project "sub" is nested inside a project "main" on the filesystem but is excluded from appearing under "main" in the resource tree via resource filters, an IWorkspaceRoot.getFileForLocation query for a location under "sub" may return the excluded resource in "main" depending on the order in which the projects are scanned. It would be more useful to always return the non-excluded resource in "sub". I encountered the problem when importing the SIF source tree (http://www.cs.cornell.edu/jif/sif/), which has a source folder containing the SIF library and subdirectories containing example programs using the library. I created a separate Java project for the library and for each example in order to separate out the build paths. Then, when I tried to run an Ant build in one of the example projects and redirect output to a file in the example project, the redirection failed because org.eclipse.debug.internal.ui.views.console.ProcessConsole tried to translate the output location back to a resource and got the excluded resource in the "library" project. Reproducible: Always Steps to Reproduce: 1. Start Eclipse on a new workspace. 2. Extract the test case (to be attached) into the workspace. It contains a "main" project and a nested "sub" project. 3. Use "Import" -> "Existing Projects Into Workspace" to import the "sub" project. 4. Run the provided "sub ant build.launch". The output is redirected to "build-log.txt". 5. Delete "build-log.txt". 6. Use "Import" -> "Existing Projects Into Workspace" to import the "main" project. 7. Run "sub ant build.launch" again. The redirection does not occur and a backtrace is written to the error log.
Created attachment 194111 [details] Test case tarball
Note that in order to run the "sub ant build.launch" launch configuration, you need to edit the file and replace 'java-1.6.0-openjdk-1.6.0.0.x86_64' by an active JRE name.
Created attachment 194123 [details] Test case tarball (hard-coded JRE removed) Oops. I have changed the launch configuration to use the default JRE.
Created attachment 194125 [details] Fix Here's a fix for this bug.
Created attachment 194128 [details] General fix Here's a more general fix. What it does is change the behavior of all the Workspace root findAll(Files|Container)** and get(File | Container)For() to have a consistent behavior regarding filtered out resources. The behavior is now that the filtered out resources won't be returned by those APIs, since the resource can't exist in the workspace. Szymon / John, can you comment on this change, and whether you think it's appropriate? Thanks.
Created attachment 194154 [details] General fix address a junit test failure for getFileForLocation for the workspace root location.
Imports should be formatted, but otherwise it looks good.
Created attachment 195089 [details] Revised fix Revised fix: documentation clarification
Created attachment 195090 [details] Revised fix Revision: sorting import statements.
Created attachment 195091 [details] Revised fix (remove files inadvertently include in the patch)
Created attachment 195092 [details] Revised fix updating copyrights
Created attachment 195094 [details] Revised fix update documentation wording
Created attachment 195096 [details] Minor changes to the patch above Moreover FSRM#pathForLocation may be removed now I think.
Created attachment 195097 [details] Latest patch now remove unnecessary code in FSRM
Created attachment 195099 [details] Latest patch remove reference to resource filters in the documentation of FileSystemResourceManager.allPathsForLocation
This is now fixed on cvs head.
