Community
Participate
Working Groups
Build: 3.2.1 final If you have multiple Java projects in a cycle, and more than one of those projects has build path errors (missing class files on build path), then you can get into a state where the build runs forever. I will attach the test case.
Created attachment 51803 [details] Plugin that adds a post build listener
Created attachment 51804 [details] Library that simulates broken build path
Created attachment 51805 [details] Two java projects that require each other (zipped)
Steps to reproduce: 1) Install the plugin in comment #1 2) Put the bad-library.jar file in c:\temp (comment #2) 3) Open a new workspace 4) Under Window->Preferences->Java->Compiler->Building, set the following: Uncheck "Treat configurable errors like fatal errors", uncheck "Abort build when build path errors occur", set "Incopmlete build path" to warning, and set "Circular dependencies" to Warning. 5) Import the projects in the attached zip (comment #3) 6) Click the Eclipse icon button in the toolbar (labeled "Adds a build listener") 7) Touch any file in one of the two projects (open in editor, hit space bar, save) -> An infinite loop of building gets kicked off. Here is what happens: 1) J1 builds partially, and then aborts when the missing class file is hit. It still produced one good class file, so there is a delta for this project. 2) J2 starts due to change in J1. It builds partially, and then aborts due to build path error. It also produces one good class file. 3) Another plugin runs a post-build listener that launches a job. The job does a no-op workspace runnable 4) Autobuild job starts due to runnable in 3). It analyzes the resource deltas, and sees changes for J1 so it calls the builder on J1. 5) Goto 1)
Reproduced with 3.2 maintenance.
Current thinking is that solving bug 114349 is going to address this one as well, since compilation will stop aborting, and will keep making progress.
I assume fixing bug 114349 would also help for large workspaces that don't have cycles. Presumably in such a workspace, every time an editor is saved, autobuild would attempt to rebuild the projects with build path errors from scratch. Another solution Kent and I discussed, which seemed less optimal, is to do a "clean" on the project when a build path error occurs, so no delta is issued for that project. This would prevent the ripple effect on downstream projects.
I don't get how the clean would avoid looping, since as long as autobuild kicks in due to listener, Java builders would get invoked and try to perform from scratch since there is no build state... or I missed something. BTW, This is not a new problem, and our fix (bug 114349) for it is very very scary for issuing this fix in a maintenance stream. We need to exercise/test it extensively (including self-hosting). So we may post it as a preview of 3.2.2 (and even committing it for 3.2.2 may be too risky). Definitely we can provide as is on the JDT page. We would however target addressing it for 3.3. What I am afraid of is the ripple through the tooling stack, because of the compiler change involved. We basically stop aborting builds in these scenarii, and pretend we have a fake empty binary type instead... something we want to calibrate based on usecases we encounter... FYI - Harmony is also interested by this fix, see bug 114349 for their workaround. Maybe it can be applied to your usecase (provide stubs on the buildpath)
Maxime 1. Pls check also that we can recover incrementally for the errors by adding the missing files as source files in the project (need to monitor classfile produced). 2. Easier scenario is: recovering from fixing the buildpath (causing full build)
> I don't get how the clean would avoid looping, since as long as autobuild kicks > in due to listener, Java builders would get invoked and try to perform from > scratch since there is no build state... or I missed something. The builder would run on P1. It would start building, and then bail out due to build path errors, but also wipe out any changes it had made. When we go to compile P2, we see there are no deltas so the builder on P2 is never called, thus breaking the cycle. In theory, at least ;) I think the fix to avoid aborting is a better solution.
Created attachment 51947 [details] Test cases for R3_2_maintenance stream These two test cases reproduce the behavior described by John, one using a jar file, the other using class folders. See MultiProjectTests#0100 and 0101, deactivated for now. Preliminary patches for bug 114349 do succeed on those tests.
Patch https://bugs.eclipse.org/bugs/attachment.cgi?id=51996 suggested for bug 114349 fixes the problem.
Fixed with same changes as bug 114349
Released for 3.3 M5 in HEAD stream Released for 3.2.2 in R3_2_maintenance stream
Verified for 3.2.2 using build M20070112-1200.
No more infinite loop with the given test case. Verified for 3.3M5 using I20070205-0009. John, you might want to verify yourself if you have another test case not reported here.
