Table of Contents
This chapter contains a few useful tips for troubleshooting build script errors.
When a build script fails, it prints an error message and one or more stack traces. Most errors are logged twice because many script language implementations do not propagate all error information in the exceptions that they receive. This results in a very long list of stack traces. The rule of thumb is that the most useful stack trace information is logged first.
When faced with an error that is non-trivial to diagnose, what can you do? Here follows a few tips:
By increasing the report level to FINE,
FINER or even
FINEST for the failing task, it may print useful
debug information before it fails. Do this by calling
setReportLevel on its task factory.
A task can be made to trace log its configuration before it is run. Trace logging can either be enabled in three different ways:
traceMode
property of TraceMode or by using the
--trace flag when launching Schmant.traceLogging property.traceLogging property.
Errors can be made more difficult to diagnose by running several build
threads. If using a TaskExecutor, set the number of build
threads to one by setting the numberOfThreads
property.
By default, Schmant deletes all temporary directories created using the
TempFileUtil when it exits. If Schmant is launched with
the -k flag, temporary files and directories
are not deleted.
A remote debugger can be used for debugging calls to Java code made by a build script. Unfortunately, there is no way to attach a debugger to the script itself.
To use a remote debugger, launch Schmant with (for instance) the
following JVM options (the -j flag):
-j -agentlib:jdwp=transport=dt_socket,server=y,address=localhost:28000,suspend=y.