On 19/09/2012, at 6:40 AM, Hans Dockter wrote: > Here we go: > > gradle -v > ------------------------------------------------------------ > Gradle 1.3-20120918133742+0000 > ------------------------------------------------------------ > > Gradle build time: Tuesday, September 18, 2012 1:37:42 PM UTC > Groovy: 1.8.6 > Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012 > Ivy: 2.2.0 > JVM: 1.6.0_35 (Apple Inc. 20.10-b01-428) > OS: Mac OS X 10.8.1 x86_64 > > 1.) No daemon startet up and calling gradle jettyRun > > Output: > :classes UP-TO-DATE > > Building > :jettyRun > Running at http://localhost:8080/quickstart > > jps: > 53026 GradleMain > 53033 GradleDaemon > > After ctrl-c jps yields no daemon processes. Is that the intendent behaviour.
That's what is expected yes. If the client process terminates abnormally, then the daemon tears itself down. To “fix” this, we'd have to add some signal handling stuff to Gradle. The daemon client would have to catch the signal, forward it to the daemon server and give the Jetty code a chance to interpret this as a request to shutdown Jetty and nothing else. I'll assume we could simulate this kind of signalling on windows somehow. > 2.) What I can't reproduce right now, but I'm pretty sure happened yesterday > a couple of time is that ctrl-c is stopping the build but not shutting down > jetty and the daemon was still running. Then running another build created > another daemon process. This is specifically intended not to happen. We force shut down the Daemon JVM so that misbehaving build code cannot keep it open. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
