Dear Benjamin,
thank you for your statement. I agree that the
StackOverflowError is a subsequent fault. And I know that is not really
necessary to implement the method getMessage. The sample that I gave was kept
very simple. In our productive source code it is a little bit more complex. But
this is not my point behind the issue.
My issue is following: In this case a task failed and
my expectation is that Gradle terminates therefore with “BUILD FAILED”. But at
least in this use case two StackOverflowError (one during serializing and one
during deserializing Objects) occurred in Gradle AND then gradle terminates
with “BUILD SUCCESSFUL”. My expectation
is that gradle is unsusceptible against such tasks or tests. Otherwise it could lead to situations
where for example CI servers executes regularly the build, gradle terminates every
time with “BUILD SUCCESSFUL”, but in truth there is serious problem with one of
the tasks or source code.
By the way: As part of the migration to gradle of the
build process of another product also a StackOverflowError occurred (compare StackOverflowError during parallel build).
But for this second case the
StackOverflow it is not so easy to create a small sample. And in this second
case all tests could be executed successfully.
Cheers
Markus