Bug 177367 - nesting linked folders doesn't work due to linked resources order is not preserved in .project file
Summary: nesting linked folders doesn't work due to linked resources order is not pres...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M7   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2007-03-14 12:31 EDT by Jacek Pospychala CLA
Modified: 2007-03-28 16:00 EDT (History)
1 user (show)

See Also:

Attachments
sort links before synchronizing them with with filesystem (2.04 KB, patch)
2007-03-23 05:56 EDT, Jacek Pospychala CLA 		no flags Details | Diff
Updated patch (2.69 KB, patch)
2007-03-28 15:28 EDT, John Arthorne CLA 		no flags Details | Diff
Test case (2.41 KB, patch)
2007-03-28 15:29 EDT, John Arthorne CLA 		no flags Details | Diff
Show Obsolete (1) 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 Jacek Pospychala CLA 2007-03-14 12:31:46 EDT 
I have a project with two linked folders defined like this:

<linkedResources>
		<link>
			<name>aaaaaaaA</name>
			<type>2</type>
			<location>C:/somewhere/a</location>
		</link>
		<link>
			<name>aaaaaaaA/b</name>
			<type>2</type>
			<location>C:/somewhere/b</location>
		</link>
	</linkedResources>

Linked folders should be created in order exactly as in .project file.
But when importing a project, when .project file is read, link entries are stored in HashMap and their order is not preserved.

Now when aaaaaaaA/b link is created, it requires it's parent to exist and consequently aaaaaaaA directory is created. Following that aaaaaaaA link is ignored.

Workaround: not use nested folders
Proposed solution: take order information into account when reading .project file
Comment 1 John Arthorne CLA 2007-03-14 14:50:13 EDT 
Possibly related to bug 177148
Comment 2 Jacek Pospychala CLA 2007-03-15 04:12:00 EDT 
(In reply to comment #1)
> Possibly related to bug 177148
> 

John you're right, but I created this one to narrow down the issue. Now i am working on a patch for it and would be happy if it also fix bug 177148 but i am not sure if it really be that easy.
Comment 3 Jacek Pospychala CLA 2007-03-23 05:56:24 EDT 
Created attachment 61792 [details]
sort links before synchronizing them with with filesystem

when reconciling links, sort them first so nested links will never be created before their parents
Comment 4 John Arthorne CLA 2007-03-28 13:15:32 EDT 
Assigning to myself to review patch
Comment 5 John Arthorne CLA 2007-03-28 15:28:10 EDT 
Jacek, I like this solution.  It has minimal impact on the code, and nicely inserts the fix in the exact place it is needed.  It is important in the resources component that all fixes be accompanied by an automated JUnit test.  This ensures the same bug doesn't slip back in in the future.  I have written a test for this, and I will attach it here for your reference.

The only other minor change is that I found the new PathLengthComparator class to be unnecessary.  I have instead made LinkDescription implement Comparable and put the comparison code there.  Also, I changed the sort slightly so that it's a real topological sort. It has the same effect in this case and similar performance, but I prefer a logical sort implementation because it may be useful in the future (sorting paths based on their string representation creates an unusual sort order).

Thank you for the patch. I am running the entire test suite now, and will release when I verify that all tests pass.
Comment 6 John Arthorne CLA 2007-03-28 15:28:41 EDT 
Created attachment 62276 [details]
Updated patch
Comment 7 John Arthorne CLA 2007-03-28 15:29:05 EDT 
Created attachment 62277 [details]
Test case
Comment 8 John Arthorne CLA 2007-03-28 16:00:39 EDT 
All tests pass. Fix released.