Bug 43847 - IPackageFragment not updated after CUs have moved
Summary: IPackageFragment not updated after CUs have moved
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 critical (vote)
Target Milestone: 3.0 M4   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-29 13:51 EDT by Dirk Baeumer CLA
Modified: 2003-10-14 10:19 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Baeumer CLA 2003-09-29 13:51:59 EDT
I20030925 + JDT/Core build input for 20030930

The failing test case is MoveTest. Here is what happens:

- we create a Java project with a source folder
- the source folder contains
  p1 with cus A.java and B.java
  p2 with cu C.java
- then we move the two cus from p1 to p2 using the following Java/Core API:
  getCu().move(getDestinationPackage(), null, newName, true, pm);
  Both the cu to move (e.g. call getCu()) and the destination package are
  recreated from handles (e.g. strings like "=TestProject1064857227528/src<p1
{A.java"

- after moving the cus a call getChildren() to the package fragment p1 created 
  in the test returns the two children A.java and B.java.

- checking on the file system reveals that they have been correctly moved to
  p2.
Comment 1 Dirk Baeumer CLA 2003-09-29 13:59:02 EDT
Even pack1.getResource.refreshLocal() doesn't bring the package back in sync 
with the underlying file system.
Comment 2 Philipe Mulet CLA 2003-09-29 17:55:54 EDT
If the resource is in sync already, refreshing it doesn't do anything. 
The only relevant thing to try is close/reopen project to force a model update.
Comment 3 Philipe Mulet CLA 2003-09-30 04:56:50 EDT
Problems comes from a breaking change in the platform with change 
notifications. 

Now long running operations may broadcast intermediate refresh notifications, 
thus revealing internal aspects. This issue has been reported already by PDE, 
and we believe this could be a problem in our JDT tests, since we are assuming 
a workspace runnable is queuing all change notifications until the end (and 
thus expect a very specific shape of batched delta, we may no longer rely 
upon). 

This accounts for some random JDT Core test failures in integration/nightly 
build. 

Now we realize it is actually even worse, since our Java model operations too 
are strongly relying on IWorkskaceRunnable to batch all changes until the end. 
In this particular scenario the resource move is notified prior to the fine 
grain Java delta (type rename) which is causing trouble to clients who are 
getting 2 volleys of notifications.

Comment 4 Philipe Mulet CLA 2003-09-30 05:09:30 EDT
Actually, there is a model inconsistency on our end too. Need to investigate.
Likely the delta change gets us in an unexpected situation.
Comment 5 Jerome Lanneluc CLA 2003-09-30 07:48:03 EDT
DeltaProcessor was filtering too much and not updating the Java model.
Fixed and added regression test WorkingCopyOwnerTests.testMoveWorkingCopy()
Comment 6 David Audel CLA 2003-10-14 10:19:05 EDT
Verified.