FAILURE: Build failed with an exception.
* What went wrong:
Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at https://docs.gradle.org/4.9/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
FAILURE: Build failed with an exception.
* What went wrong:
java.lang.ExceptionInInitializerError (no error message)
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
You’ve posted a generic error with none of the details that would be necessary to determine what’s causing it in your particular case. Any of the options in Try: would be a good starting point.
To put the GradleDaemons (processes) that have become Zombies out of their misery, use the code depicted in the two screenshots (actually use the ‘ps’ to verify the efficacy of the cullany ßash shell function).
This anomaly, the Ant-Option and DSL spaghetti are all reasons to use Maven, just sayin’.
Column #2 in Readout is the PID | Grep for this token: GradleDaemon
ps aux | grep GradleDaemon | grep -v grep
And what do you want to tell us with your totally thread-unrelated random rant, besides that you don’t really know Gradle and also don’t like Gradle?
If you prefer Maven, by all means, use it. Everyone his tool. Being too used to Maven to learn and use something newer and better is one of the few reasons I can accept for still using Maven these days. But do I go to Maven forums, posting to random threads “writing XML for logic is so ugly and extending Maven is so cumbersome, all a few of the many reasons to use Gradle”? No, because that would be pretty trollish behavior.
Btw. you can simply stop all daemons of the same Gradle version using the --stop command line option.
And what do you want to tell us with your totally thread-unrelated random rant, besides that you don’t really know Gradle and also don’t like Gradle?
Well let’s see funny man: Daemons are of course PROCESSES (never claimed they were as economical as threads). AND, Maven never has experienced this dead processes issue (points for Maven). This ZOMBIE behavior of dead Daemons should never necessitate a “-stop” switch, and as a major impediment to one of my recent clients “Vampire”. Go suck blood (form a rock).
I was not talking about Java threads, I’m talking about this forum thread.
You are posting a random rant here that has nothing to do with the topic of this thread.
I use Gradle since many years and never had problems with “dead processes” or “zombie processes”.
If you think you found some issue, it would be way more productive if you open a bug report in the issue tracker, instead of bullying around in a community forum.
All software has bugs, a bug-free software does not exist. Of course Gradle has bugs and maybe you are hitting one with getting zombie processes. Maven has bugs too. For every “point” you count for Maven due to a bug in Gradle, you can as well assing a bug to Gradle for some random Maven bug or quirk, that’s not really helpful. Maven might not use a daemon process and thus might not get the problem of stale processes, but on the other hand, the Gradle daemon is one of the major building blocks for some of the performance improvements Gradle provides over Maven, so big point for Gradle. Can it have bugs? Of course it can, it is software, so it most certainly does. If you don’t care about build performance, you could even disable that the daemon keeps running after the build on a per-project or even per-user basis (or even per invocation).