Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343914

Summary:

IWorkspaceRoot.getFileForLocation with nested projects and resource filters

Product:

[Eclipse Project] Platform

Reporter:

Matt McCutchen <hashproduct+eclipse>

Component:

Resources

Assignee:

Serge Beauchamp <serge>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

john.arthorne, serge, Szymon.Brandys

Version:

3.6.1

Flags:

Szymon.Brandys: review+

Target Milestone:

3.7 RC1

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Test case tarball	none
Test case tarball (hard-coded JRE removed)	none
Fix	none
General fix	none
General fix	none
Revised fix	none
Revised fix	none
Revised fix	none
Revised fix	none
Revised fix	none
Minor changes to the patch above	none
Latest patch	none
Latest patch	none

Description Matt McCutchen

2011-04-26 17:43:55 EDT

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.

Comment 1 Matt McCutchen

2011-04-26 17:44:47 EDT

Created attachment 194111 [details]
Test case tarball

Comment 2 Serge Beauchamp

2011-04-27 02:31:18 EDT

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.

Comment 3 Matt McCutchen

2011-04-27 02:53:45 EDT

Created attachment 194123 [details]
Test case tarball (hard-coded JRE removed)

Oops.  I have changed the launch configuration to use the default JRE.

Comment 4 Serge Beauchamp

2011-04-27 03:15:57 EDT

Created attachment 194125 [details]
Fix

Here's a fix for this bug.

Comment 5 Serge Beauchamp

2011-04-27 04:20:37 EDT

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.

Comment 6 Serge Beauchamp

2011-04-27 09:45:33 EDT

Created attachment 194154 [details]
General fix

address a junit test failure for getFileForLocation for the workspace root location.

Comment 7 Szymon Brandys

2011-05-09 11:23:05 EDT

Imports should be formatted, but otherwise it looks good.

Comment 8 Serge Beauchamp

2011-05-09 11:41:39 EDT

Created attachment 195089 [details]
Revised fix

Revised fix: documentation clarification

Comment 9 Serge Beauchamp

2011-05-09 11:43:10 EDT

Created attachment 195090 [details]
Revised fix

Revision: sorting import statements.

Comment 10 Serge Beauchamp

2011-05-09 11:45:19 EDT

Created attachment 195091 [details]
Revised fix

(remove files inadvertently include in the patch)

Comment 11 Serge Beauchamp

2011-05-09 11:48:08 EDT

Created attachment 195092 [details]
Revised fix

updating copyrights

Comment 12 Serge Beauchamp

2011-05-09 11:52:32 EDT

Created attachment 195094 [details]
Revised fix

update documentation wording

Comment 13 Szymon Brandys

2011-05-09 12:02:34 EDT

Created attachment 195096 [details]
Minor changes to the patch above

Moreover FSRM#pathForLocation may be removed now I think.

Comment 14 Serge Beauchamp

2011-05-09 12:13:17 EDT

Created attachment 195097 [details]
Latest patch

now remove unnecessary code in FSRM

Comment 15 Serge Beauchamp

2011-05-09 12:20:37 EDT

Created attachment 195099 [details]
Latest patch

remove reference to resource filters in the documentation of FileSystemResourceManager.allPathsForLocation

Comment 16 Serge Beauchamp

2011-05-09 12:24:26 EDT

This is now fixed on cvs head.