Resolution: Not A Bug
Affects Version/s: 1.0-milestone-3
Fix Version/s: None
Medium-sized projects often have long-running tasks. It is just the nature of the human beast that sometimes the builder will want to abort a build after they have fired it off... usually to adjust some setting or do something that they forgot to do. Or maybe they saw some build output in the console indicating that the build should not proceed.
(When I say builder in this Description, I mean the person doing builds, not any Builder class or anything like that).
Every command-line build tool tool, including Gradle's, allows you to abort builds (usually with Ctrl-C). Every modern Java IDE that I have used allows you abort their native builds (Eclipse provides a Cancel button). It is unacceptable to require builders to use kill commands or Windows' Task Manager to stop run-away build processes.
This single short-coming prevents me from standardizing on Gradle for workstation builds for my team. Our team includes some command-line-phobes who can't handle any console-based work. (I wouldn't retain such workers, but that's not my decision). I just can't propose an improvement where accidental build invocations must be allowed to run for 20 minutes before work can resume. (I know that another task-execution could be invoked to run concurrently, but that causes even worse problems as the two processes race to use, move, and remove the same files).
I have so far been unable to find the source code file where the new task-runner JVMs are forked and managed by the GUI. If you want me to submit a patch for this enhancement, please contact me or update the ticket with location of relevant code and any relevant tips.