Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 268507 - Changing a linkLocation using #setLinkLocation doesn't automatically update child resources
Summary: Changing a linkLocation using #setLinkLocation doesn't automatically update c...
Status: RESOLVED FIXED
Alias: None
Product: e4
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 0.9 M2   Edit
Assignee: Serge Beauchamp CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-13 06:36 EDT by James Blackburn CLA
Modified: 2009-03-16 11:12 EDT (History)
1 user (show)

See Also:

Attachments
Test 1 (3.08 KB, patch)
2009-03-13 06:36 EDT, James Blackburn CLA 		john.arthorne: iplog+
Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description James Blackburn CLA 2009-03-13 06:36:27 EDT 
Created attachment 128680 [details]
Test 1

Build ID: HEAD

Steps To Reproduce:
IResource#setLinkLocation(childLoc, IResource.NONE, getMonitor());

I'm seeing the resources under the linked resource not being automatically refreshed / updated.  The API doesn't mention this, in fact there's a BACKROUND_REFRESH flag which can be passed for the refresh not be done in-line (a la Open Project).

Having a look at the code Resource#setLinkLocation does:
if ((updateFlags & IResource.BACKGROUND_REFRESH) != 0) {
	workspace.refreshManager.refresh(this);
	monitor.worked(Policy.opWork * 90 / 100);
} else {
	refreshLocal(DEPTH_INFINITE, Policy.subMonitorFor(monitor, Policy.opWork * 90 / 100));
}

which suggests that the IResource should be up to date after the setLinkLocation call.


More information:
Test attached
Comment 1 Serge Beauchamp CLA 2009-03-13 09:44:58 EDT 
Comment:  this is not a problem with setLinkLocation(), I suspect this is a problem with the alias manager.

doing the following works properly:

			nonExistingFolderInExistingProject.setLinkLocation(childLoc, IResource.NONE, getMonitor());

			assertTrue("2.0", existingFolderInExistingFolder.members().length == 1);
			assertTrue("3.0",  existingFolderInExistingFolder.members()[0].getName().equals("foo"));
			assertTrue(nonExistingFolderInExistingProject.getLocation().equals(childLoc));
			assertTrue("2.0", nonExistingFolderInExistingProject.members().length == 1);
			assertTrue("3.0",  nonExistingFolderInExistingProject.members()[0].getName().equals("foo"));

			nonExistingFolderInOtherExistingProject.setLinkLocation(parentLoc, IResource.NONE, getMonitor());

but since the unit test calls both setLinkLocation() successively, it fails, as follows:

			nonExistingFolderInExistingProject.setLinkLocation(childLoc, IResource.NONE, getMonitor());
			nonExistingFolderInOtherExistingProject.setLinkLocation(parentLoc, IResource.NONE, getMonitor());

			assertTrue("2.0", existingFolderInExistingFolder.members().length == 1);
			assertTrue("3.0",  existingFolderInExistingFolder.members()[0].getName().equals("foo"));
			assertTrue(nonExistingFolderInExistingProject.getLocation().equals(childLoc));
			assertTrue("2.0", nonExistingFolderInExistingProject.members().length == 1);
			assertTrue("3.0",  nonExistingFolderInExistingProject.members()[0].getName().equals("foo"));

This is because the second setLinkLocation somehow messes up the alias of the first one.
Comment 2 Serge Beauchamp CLA 2009-03-13 13:22:24 EDT 
This is now fixed on the e4 resource CVS HEAD.  The included regression test
passes successfully.
Comment 3 James Blackburn CLA 2009-03-16 11:12:53 EDT 
Thanks Serge!