Description Walter Harley 2006-12-01 01:39:19 EST

A Java build starts by JavaBuilder.initializeBuilder() calling CompilationParticipant.aboutToBuild() for each participant.  The purpose of this call is in part for the participant to make sure that it has the resources it needs to build - in particular, to create any output directories it needs.

The build then goes on to call isWorthBuilding(), which calls isClassPathBroken().  But rather than actually checking the classpath, all that does is look at existing markers to see if there are any classpath problems.

If there is a missing directory that is a source path (e.g., the APT generated source folder), then there will be a classpath error marker.  Ideally when the participant (APT) creates the missing directory, it would also remove the error marker; but it can't, because the participant has no way of knowing which marker(s) to remove.

So instead what happens is that build is aborted because of the unbound source folder; and then, hopefully, a resource change event triggered by creation of the directory causes a subsequent build to occur.

In practice, that resource event seems a bit unreliable.  We are encountering situations where the change event does not seem to be getting noticed, or if it is getting noticed it is getting thrown away again, possibly because there are conflicting jobs in the queue at the same time.

So we would like a more reliable approach.  I think a good approach would be, if isClasspathBroken() returns true, to actually validate the classpath again before aborting the build.

I have tested this approach and it does fix some nasty bugs we're fighting.  However, I don't know whether I've done it the most efficient or correct way.  I'll attach the patch that I've been using as a sample.