Open Charlweed opened 5 years ago
I'm almost certain this is because the plugin tries to read the stdout produced by the tests and it is too big. Would it be all right, if I put a global limit on the maximum length of stdout (and stderr) read?
I think that sounds OK, because of course, I don't really want to read all the exceptions. It is possible to display a warning if the plugin knows that it has truncated stdout? And it would also be nice if there was a set-able property for the size of whatever heap is being exhausted.
It is possible but I would prefer to have the first line start with something like [stdout/stderr was truncated]. And of course, I would like to make the size configurable (I just hate messing with the UI and worrying if resizing and whatnot didn't get broken).
I have a testcase which spews exceptions, and that crashes the gradle plugin, and I must restart NetBeans. I have tried setting the heap to 8 gigs(!) of ram or more, everywhere I can. I tried in netbeans.conf, settings,gradle, build.gradle, and in .nb-gradle-properties with the UI. In fact, the console shows that gradle starts with -Xmx10g But the NetBeans test UI never displays anything, even though I think they finish. Instead I get the error dialog with the exception below. When I run gradlew from the command-line, the tests complete as expected, showing the exceptions. I also see the exceptions on the console when I run BuildShip in Eclipse. The wrapper version of gradle is 4.10. NetBeans 9 Windows 7 amd64
The project is git@github.com:RPTools/maptool.git, and the sub-project is maptool, but the testcase with the hundreds of exceptions is my own.