Handling of build exceptions in Gant.groovy

View: New views
1 Messages — Rating Filter:   Alert me  

Handling of build exceptions in Gant.groovy

by Eric Van Dewoestine :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

As I mentioned in my previous mail, I'm new to gant and have been
converting my existing ant build files to it, making use of the gant
ant task so that my users can continue to use ant to build my project.

One issue I've run into is the way that groovy/gant/Gant.groovy
handles build exceptions.  When it catches an exception from the build
it wraps that exception in a TargetExecutionException.  The wrapping
of the exception, I suspect, probably provides a useful function when
using gant directly, but when invoked by ant, this wrapping of the
original exception can be problematic.

I've run into two issues, but the root issue is that when an ant
BuildException is caught and then wrapped in a
TargetExecutionException, it is no longer a descendant of ant's
BuildException which causes ant to treat the exception quite
differently.  When ant catches a BuildException it will suppress the
stack trace associated with that exception (unless you add the -debug
flag) and simply print a normal ant failure message that ant users
should be accustom to.  When ant catches the TargetExecutionException,
it will print out its stack trace, which in turn will print the root
exception stack trace leading to two very large stack traces dumped
onto the screen.  This can prove to be rather annoying when such an
error is encountered.

A slightly worse case arises if the gant build file issues a call to
ant.fail(message: "some message"), which will again result in the two
very large stack traces.  Since ant.fail can be commonly used to abort
a build and report useful information to the user, having that
information buried in stack traces can severely affect the usability
of the build file.

In my case I resolved this issue by simply commenting out the wrapping
of the original exception in Gant.groovy and simply re-throw it after
the attemptFinalize call.  However, I'd imagine that this wouldn't be
the proper solution to adopt in gant.  Perhaps a better solution would
be to alter GantException to extend ant's BuildException instead of
RuntimeException?  I haven't attempted that yet as I'd like to hear
the opinion of the gant developers in this area.

I've attached a simple test case where I have a gant target that
invokes the fail task and when invoked from the included ant script
exhibits the issue I've described.  In my case I've invoked the
example like so:

$ ant \
  -Dgroovy.home=/usr/local/java/src/groovy-1.6.5 \
  -Dgant.home=/usr/local/java/src/gant-1.8.1

--
eric


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

gant-buildexception.tar.gz (586 bytes) Download Attachment