- integrated the newer release of remoting
- jar caching won't work with class file directory, so plugin
WEB-INF/classes are now exploded as WEB-INF/lib/classes.jar
(This should also solve the problem of slow plugin extraction in the
presene of Anti-virus software on Windows.)
- because the structure of the exploded jar file has changed, I changed
the up-to-date check timestamp file name to force re-extraction in
existing installations.
Not really solving anything here—there is no plausible implementation that could run under these circumstances—
but at least reporting the problem more clearly.
Happens when build has no parent:
15:06:14 FATAL: null
15:06:14 java.lang.NullPointerException
15:06:14 at hudson.matrix.MatrixBuild$MatrixBuildExecution.doRun(MatrixBuild.java:371)
15:06:14 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580)
15:06:14 at hudson.model.Run.execute(Run.java:1575)
15:06:14 at hudson.matrix.MatrixBuild.run(MatrixBuild.java:304)
15:06:14 at hudson.model.ResourceController.execute(ResourceController.java:88)
15:06:14 at hudson.model.Executor.run(Executor.java:237)
15:06:14 at hudson.model.OneOffExecutor.run(OneOffExecutor.java:66)
@kohsuke confirms that the intent of throwing AIOOBE was to track down definite code errors;
but in at least some known occurrences of this bug, the problem is invalid data:
build records on disk with <number>s that are duplicated and/or out of order.
Since that violates the precondition of the class, we do not pretend to successfully search for such records.
At some point it would make sense to have the code detect anomalous conditions and initiate a builds folder cleanup.
Take only the last build of a given number, and discard any earlier with higher number.
I.e. just set <number> to 0 or something and ignore such builds, or rename build.xml to build-broken.xml.
Note that when workaround is active, table will not get sorted properly.
Probably OK since tables with large contents that *need* sorting probably take longer to finish rendering.