Bugzilla – Full Text Bug Listing
| Summary: | [common navigator] newly created project disappears in Project Explorer | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Kaloyan Raev <kaloyan> | ||||
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P2 | CC: | bokowski, daniel_megert, francisu, markus.kell.r, martinae | ||||
| Version: | 3.4 | Flags: | daniel_megert:
review+
|
||||
| Target Milestone: | 3.4.1 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Kaloyan Raev
3.4.1 candidate? (if reproducible) I was also seeing new projects being created today in my testing and not appearing. Then when I closed another project, the new project appeared. This is certainly for 3.4.1, and I'm pretty sure I will be able to repro it. This might be related to or even caused by bug 244358 (double remove of a deleted project). I was able to occasionally reproduce this using your instructions, and one thing I noticed in the tracing is that one of the remove() calls from the previous delete was being made after the project was added. The remove calls are made asynchronously, though I'm not sure how they could get so far out of order. I would be interested in any comments from the JDT folks. I don't think this particular problem has anything to do with the fix to bug 208462. There are many possible reasons for refresh problems; this appears different. I'm going to continue to work on reproducing this and capturing stack trace information for the out of sequence remove() calls and hopefully that will tell us something. >This might be related to or even caused by bug 244358 (double remove of a >deleted project). Nope, double remove/add is unfortunately needed and in since day one of CN (R3.2), see other bug for details. I suspect that the reason we see this now is the fix made for bug 184991. Adding Martin for comment. Francis, I cannot reproduce this on my machine. A test case (not manually but in the test plug-in) would be good. I have an improved fix for bug 184991 but I would need to know whether this really is the cause for this bug here. I could also give it to you to test if you want. (In reply to comment #5) > A test case (not manually but in the test plug-in) would be good. hehe, wouldn't we all love that. Sadly, don't have one of those. It was hard for me to reproduce it on my machine manually, it happened according to the instructions quite rarely. I have an improved fix for bug 184991 but I > would need to know whether this really is the cause for this bug here. I could > also give it to you to test if you want. Yes, I would be interested in this. >Yes, I would be interested in this.
Today's I-build and HEAD (org.eclipse.jdt.ui) contains the fix.
(In reply to comment #7) > >Yes, I would be interested in this. > Today's I-build and HEAD (org.eclipse.jdt.ui) contains the fix. > It's in PackageExplorerContentProvider? I'm mainly interested in looking at it; not that I expect to get any better at reproducing this problem. >It's in PackageExplorerContentProvider? I'm mainly interested in looking at
>it; not that I expect to get any better at reproducing this problem.
Yes. And I'm interested in whether it helps with that bug ;-)
This problem can be reproduced (even on the first 'Next' click) when you
manually delay the update job in
PackageExplorerContentProvider.postAsyncUpdate(Display), e.g. by changing the
last line to
fUpdateJob.schedule(10*1000);
The fix for bug 244514 does unfortunately not fix (nor otherwise affect) this
problem.
The problem is in JavaNavigatorContentProvider.postAdd(Object, Object, Collection):
if (parent instanceof IJavaModel)
super.postAdd(((IJavaModel) parent).getWorkspace(), element, runnables);
This is effectively a no-op, since the IWorkspace from getWorkspace() is not in the tree model. The fix is simply to add getRoot().
This code is called by PackageExplorerContentProvider.processDelta(..):
if (elementType == IJavaElement.JAVA_PROJECT) {
[..]
// if added it could be that the corresponding IProject is already shown. Remove it first.
// bug 184296
if (kind == IJavaElementDelta.ADDED) {
postRemove(element.getResource(), runnables);
postAdd(element.getParent(), element, runnables);
return false;
}
}
Since postAdd(..) always fails, the project is missing in the end, unless the asyncExec from ResourceExtensionContentProvider comes in later and adds the project again.
Created attachment 110373 [details]
Fix
Dani and/or Francis, please review the patch. Agree to fix for 3.4.1. Released to HEAD and R3_4_maintenance. Verified in M20080827-2000. It seems to be fixed. Thanks! |