To reproduce:
create build.gradle:
apply plugin: "java"
create init.gradle:
useLogger(new CustomEventLogger())
class CustomEventLogger extends BuildAdapter implements TaskExecutionListener {
public void beforeExecute(Task task) {
println "foo"
throw new RuntimeException("foo")
println("bar")
}
public void afterExecute(Task task, TaskState state) {
println()
}
public void buildFinished(BuildResult result) {
println 'build completed'
}
}
Produces: $ gradle build -I init.gradle
foo build completed
Should produce: Some sign of exception happening
Even --stacktrace and --debug do not show exception
Seen on gradle 1.9 and 1.11
Ah, sorry. Should be more specific. Using a custom Logger swallows all Exception reporting.
The code uses the example from http://www.gradle.org/docs/current/userguide/logging.html
Maybe there is a better way to do custom logging without swallowing Exceptions.
And to be even more specific, this happens if the Listener passed to useLogger() implements BuildListener.
So at least I suggest quickly removing BuildAdapter from the example in the docs along with the buildFinished() method. Then the example works to start with.
Also, BTW: What I wanted to do was to add logging of the time the tasks finished, to get an idea of why my builds on Jenkins take so long. However, I also do not want to loose the standard gradle outputs like SKIPPED, UP-TO-DATE, and so on, and I do not wish to reimplement the logging.
Would be nice if the documentation example rather showed how to do that, how to extend TaskExecutionLogger in a viable way maybe.
Hi Thibault,
I read through those docs and I think they are accurate. The first sentence of the code example you linked to says: “You can replace much of Gradle’s logging UI with your own”. This feature is not designed to be used to extend Gradle’s logging, but rather replace it.
If you want to extend the logging you would just add the listener via ‘addListener()’ and not ‘useLogger()’.
1 Like
Hi Luke,
I can add a Listener using addListener() instead to solve my problem, thanks. ‘–profile’ is nice, but I did not find any nice jenkins integration, and I would like the information to be available in the log output. I guess I could parse the --profile output file if it exist and print that…
The logging documentation may be accurate, but it is still not helpful. It tempts users to modify their buildsystem to swallow exceptions without giving fair warning. At least the example could check the taskState in afterExecute and print a stacktrace on Exception.
regards,
Thibault
At least the example could check the taskState in afterExecute and print a stacktrace on Exception.
That’s a good idea. I’ll make that change. Thanks.
1 Like