Community
Participate
Working Groups
Build Identifier: M20090211-1700 We have a customer who gets different number of build path errors when using auto-build vs manual build. In the first case, this code creates the invalid classpath marker: Thread [Worker-14] (Suspended (breakpoint at line 639 in Resource)) Project(Resource).createMarker(String) line: 639 JavaProject.createClasspathProblemMarker(IJavaModelStatus) line: 805 ClasspathValidation.validate() line: 73 DeltaProcessor.resourceChanged(IResourceChangeEvent) line: 1969 DeltaProcessingState.resourceChanged(IResourceChangeEvent) line: 431 NotificationManager$2.run() line: 288 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 282 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastBuildEvent(Object, int, int) line: 297 AutoBuildJob.doBuild(IProgressMonitor) line: 136 AutoBuildJob.run(IProgressMonitor) line: 238 Worker.run() line: 55 Debugging a bit further, I could see that this listener was stripping off the invalid classpath marker after it was created, thus leading to the exception in the Java Builder: Thread [Worker-18] (Suspended) LaunchingPlugin.resourceChanged(IResourceChangeEvent) line: 754 NotificationManager$2.run() line: 288 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 282 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastBuildEvent(Object, int, int) line: 297 AutoBuildJob.doBuild(IProgressMonitor) line: 136 AutoBuildJob.run(IProgressMonitor) line: 238 Worker.run() line: 55 The problem is that there are two pre-build listeners. One is adding the build path validation marker, and the other one takes it away. The validation marker is needed by the builder, so there is either an ordering issue or the second listener shouldn't be deleting the marker. Reproducible: Always Steps to Reproduce: 1. Launch workbench 2. Enable auto-build 3. Import the projects 4, Wait until build completes, get x number of build path errors 5, Start another workbench 6, Disable auto-build 7, Import the projects, and wait until it settles 8, Start a manual build 9, Wait until build completes, and get y number of build path errors. 10, Found x doesn't equal to y Expected result: x should equal to y.
Where can we get the projects to load ?
Note that we couldn't reproduce this behaviour using pure Java projects, but only with our product's projects which have the JDT nature. We not ruling out that something in our product stack is running when it's not supposed to or at a time when JDT doesn't appreciate it. Can you give us a clue what would trigger this stack: Thread [Worker-18] (Suspended) LaunchingPlugin.resourceChanged(IResourceChangeEvent) line: 754 NotificationManager$2.run() line: 288 SafeRunner.run(ISafeRunnable) line: 37 NotificationManager.notify(ResourceChangeListenerList$ListenerEntry[], IResourceChangeEvent, boolean) line: 282 NotificationManager.broadcastChanges(ElementTree, ResourceChangeEvent, boolean) line: 148 Workspace.broadcastBuildEvent(Object, int, int) line: 297 AutoBuildJob.doBuild(IProgressMonitor) line: 136 AutoBuildJob.run(IProgressMonitor) line: 238 Worker.run() line: 55 Perhaps this will give us a hint at where to look to better identify where the problem lay (whether it be our product code or JDT).
This stack is triggered when a build starts and the resources that have changed since last build are processed. We must either get more details on how to reproduce this issue or this will be closed as WORKSFORME.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
