Community
Participate
Working Groups
example: https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/4102/ org.eclipse.jdt.core.tests.model.AllJavaModelTestsTracing.testChangeRootKind Unexpected delta. ----------- Expected ------------ P[*]: {CHILDREN | CONTENT | RAW CLASSPATH CHANGED | RESOLVED CLASSPATH CHANGED}\n src[*]: {ADDED TO CLASSPATH | REMOVED FROM CLASSPATH}\n ResourceDelta(/P/.classpath)[*] ------------ but was ------------ P[+]: {}\n \n P[*]: {CHILDREN | CONTENT | RAW CLASSPATH CHANGED | RESOLVED CLASSPATH CHANGED}\n src[*]: {ADDED TO CLASSPATH | REMOVED FROM CLASSPATH}\n ResourceDelta(/P/.classpath)[*] --------- Difference is ---------- expected:<P[[]*]: {CHILDREN | CONT...> but was:<P[[+]: {}\n \n P[]*]: {CHILDREN | CONT...> As far as i understand the problem is that sometimes the event of creating the project is also reported as change after starting listening for deltas startDeltas() (a racecondition with asynchronous build and refresh threads?). A solution may be to always start listening before creation and always asserting that too. Even though it occured for me in only a single test the pattern is the same in many tests of JavaElementDeltaTests. Should all be adapted?
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176417
(In reply to Jörg Kubitz from comment #0) > As far as i understand the problem is that sometimes the event of creating > the project is also reported as change after starting listening for deltas > startDeltas() (a racecondition with asynchronous build and refresh threads?). I've tried to debug that but I don't see any asynchronous code/deltas between createJavaProject() and startDeltas(). The first "P[+]: {}" delta is always sent immediately in same thread where createJavaProject() is running. I've tried to grok over it, but I can only imagine that *next* delta created by DeltaProcessor.fire(IJavaElementDelta, int) from DeltaProcessor.javaModelDeltas still contains *previously dispatched* delta, not cleared in DeltaProcessor.flush(). But I don't see how it can happen yet. > A solution may be to always start listening before creation and always > asserting that too. Even though it occured for me in only a single test the > pattern is the same in many tests of JavaElementDeltaTests. > Should all be adapted? In worst case yes, but ideally we should really understand where the wrong delta events are coming from and fix that in some way. It could be, that the problem is not *async* deltas (which would be test only issue if they just appear later on) but *broken* deltas, which is more severe...
(In reply to Andrey Loskutov from comment #2) > It could be, that the > problem is not *async* deltas (which would be test only issue if they just > appear later on) but *broken* deltas, which is more severe... I think if that would be the case, after merging your proposal we would see duplicated "P[+]: {}" in case there are delta generation issues, and that would be also useful. I will update the patch to adopt all similar tests in that class.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176417 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=d83db768b79ae8ea665a9a84d06bed709aa8bccf
(In reply to Eclipse Genie from comment #4) > Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/176417 was > merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=d83db768b79ae8ea665a9a84d06bed709aa8bccf I would keep this bug open to monitor if that change improved the gerrit success rate or not.
>>org.eclipse.jdt.core.tests.model.AllJavaModelTestsTracing.testChangeRootKind Seeing this in gerrit build quite often.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
