Bug 178213 - Compilation Unit not shown in Package Explorer after a rename
Summary: Compilation Unit not shown in Package Explorer after a rename
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.3 M7   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-20 06:06 EDT by Frederic Fusier CLA
Modified: 2007-04-27 10:08 EDT (History)
1 user (show)

See Also:


Attachments
Proposed fix and regression test (11.18 KB, patch)
2007-04-03 04:41 EDT, Jerome Lanneluc CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2007-03-20 06:06:09 EDT
Using build I20070320-0010.

In a brand new wksp, execute following scenario:
1) create a java project
2) create a class in this project, let say 'Test'
3) An editor is opened on the new created class
4) In the editor, refactor the class name from 'Test' to 'Test1'
5) Observe in Package Explorer that new name is shown: OK
6) create a new class 'Test' in same project
7) An editor is opened on the new created class
8) Observe in Package Explorer that new class 'Test' is added but disappears 
   instantaneously. After there's only 'Test1' in default package => KO
9) Close and reopen the project fixes the problem

Note that it does not occur while refactoring the class using the popup menu item in the package explorer.
Comment 1 Frederic Fusier CLA 2007-03-20 06:07:45 EDT
Feel free to change the summary, I cannot find a real good phrase to summarize this scenario...
Comment 2 Martin Aeschlimann CLA 2007-04-02 11:32:20 EDT
This is the Java element delta log:
a.) ElementChangedEvent[source=[Working copy] Test1.java[*]: {CHILDREN | FINE GRAINED | AST AFFECTED}
	Test12[+]: {}
	Test1[-]: {}]
b.) ElementChangedEvent[source=[Working copy] Test1.java[*]: {CHILDREN | FINE GRAINED}
	Test1[+]: {}
	Test12[-]: {}]
c.) ElementChangedEvent[source=[Working copy] Test1.java[*]: {AST AFFECTED}]
d.) ElementChangedEvent[source=Java Model[*]: {CHILDREN}
	Test1[*]: {CHILDREN}
		src[*]: {CHILDREN}
			p[*]: {CHILDREN}
				[Working copy] Test1.java[*]: {PRIMARY RESOURCE}]
e.) ElementChangedEvent[source=Java Model[*]: {CHILDREN}
	Test1[*]: {CHILDREN}
		src[*]: {CHILDREN}
			p[*]: {CHILDREN}
				[Working copy] Test1.java[-]: {MOVED_TO(Test12.java [in p [in src [in Test1]]])}
				Test12.java[+]: {MOVED_FROM([Working copy] Test1.java [in p [in src [in Test1]]])}]
f.) ElementChangedEvent[source=[Working copy] Test12.java[*]: {AST AFFECTED}]
g.) ElementChangedEvent[source=[Working copy] Test12.java[*]: {AST AFFECTED}]
h.) ElementChangedEvent[source=Java Model[*]: {CHILDREN}
	Test1[*]: {CHILDREN}
		src[*]: {CHILDREN}
			p[*]: {CHILDREN}
				Test1.java[+]: {}]
i.) ElementChangedEvent[source=Test1.java[*]: {CHILDREN | FINE GRAINED}
	package p[+]: {}
	Test1[+]: {}]
j.) ElementChangedEvent[source=Java Model[*]: {CHILDREN}
	Test1[*]: {CHILDREN}
		src[*]: {CHILDREN}
			p[*]: {CHILDREN}
				[Working copy] Test1.java[-]: {PRIMARY WORKING COPY}
				[Working copy] Test12.java[*]: {PRIMARY WORKING COPY}]
k.) ElementChangedEvent[source=[Working copy] Test1.java[*]: {AST AFFECTED}]

In a.), the user uses the new lightweight UI to rename type Test1 to Test12 directly in the editor
In b.), the refactoring internally reverts the change so it can invoke the original refactoring
In e.), the real refactoring takes place, CU is moved
In h.), the new type is created as Test1
In j.), the new type is opened in the editor, but the delta looks wrong: 'Test1.java' removed, 'Test12.java' modified

Thats why the package explorer removes Test1 again.
Comment 3 Jerome Lanneluc CLA 2007-04-03 01:50:58 EDT
Problem comes from a checkpoint made by refactoring in the middle of a batch operation. The working copy discard is done after the checkpoint but we still think that we're going to get a resource delta (JavaModelOperation.hasModifiedResource() returns true). Thus the delta corresponding to the working copy discard is never fired.
Comment 4 Jerome Lanneluc CLA 2007-04-03 04:41:19 EDT
Created attachment 62752 [details]
Proposed fix and regression test

The fix consists in changing DeltaProcessor#firePostChangeDelta(...) to reset the 'has modified resource' attribute on the JavaModelOperation.
Comment 5 Jerome Lanneluc CLA 2007-04-03 05:33:25 EDT
Fix and test released for 3.3M7 in HEAD
Comment 6 David Audel CLA 2007-04-27 10:08:29 EDT
Verified for 3.3 M7 using build I20070427-0010