Does JavaExec task support spawning the jvm in a new process which will outlive gradle?


(Davide Cavestro) #1

I have a task that launches gwt dev mode, and I’d like it leave the gradle process to terminate while the gwt dev mode remains alive.

At http://www.gradle.org/releases/1.0-milestone-6/docs/javadoc/org/gradle/api/tasks/JavaExec.html and http://www.gradle.org/releases/1.0-milestone-6/docs/dsl/org.gradle.api.tasks.JavaExec.html I’ve found only two methods

JavaExec copyTo(JavaForkOptions options)
JavaExec copyTo(ProcessForkOptions target)

but I’m afraid they aren’t so useful… I’d need something like the spawn attribute from ant (http://ant.apache.org/manual/Tasks/java.html) the same behavior as

ant.java (... fork: true, spawn: true ...)

Any idea?

Cheers Davide


(Davide Cavestro) #2

There’s an RFE at GRADLE-1254


(Matias Bjarland) #3

This would indeed be useful. I have written a JavaExecAsync task and supporting classes which make it possible to javaexec into a separate thread. It turns out the classes for the existing JavaExec task are actually designed to support this so this is a small change.

When using the gradle daemon the user experience is more or less what you require: the gradle command line execution returns, but the thing it started lives on…in the gradle daemon process.

However, if you end up needing to kill the gradle daemon for whatever reason, your thread and everything with it will go down in flames. Also if you end up needing to kill the thing you started, the only way of doing this is killing the gradle daemon. If you started more than one thread, there is no way of killing just one of them.

I’m also not really a fan of leaving threads around in the daemon as they might have side effects on subsequent builds. An example a side effect we have seen is when threads spawned in previous builds do error logging into the console of a subsequent build…not great when the currently executing build is sitting on a CI server and triggering a build failure on error log messages. Even without CI this behavior can be quite unintuitive.

So +1 for this feature. Voted for the JIRA.


(Hristo Stoyanov) #4

So more than an year … not fixed?


(Hristo Stoyanov) #5

I need to launch a GWT DevMode, so this seems to work:

task devMode
{
         main = 'com.google.gwt.dev.DevMode'
          classpath {[
            sourceSets.main.java.srcDirs,
         // Java source
            sourceSets.main.output.resourcesDir,
  // Generated resources
            sourceSets.main.output.classesDir,
    // Generated classes
            sourceSets.main.compileClasspath,
     // Dependencies
        ]
       }
           enableAssertions
          args =
        [
            'com.peruncs.s4g.web.gwt.S4GWebApp', // Your GWT module(s)
            '-noserver', // Prevents the embedded web server from running
            '-war', project.buildDir,
            '-extra', project.extraDir,
            '-logLevel', 'INFO'
                     ]
               maxHeapSize = '512M'
}

However, due to GRADLE-1254, my gradle console hangs (I can not fork the process). So, I ahve to use Ant Java task instead:

task devMode
{
          ant.java( fork:true, spawn:true, classname:"com.google.gwt.dev.DevMode"){
        jvmarg(value: '-Xmx512m -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005')
        arg(value: 'com.peruncs.s4g.web.gwt.S4GWebApp')
        arg(value: '-noserver')
        arg(value: '-war')
        arg(value: project.buildDir)
        arg(value: '-extra')
        arg(value: project.extraDir)
        arg(value: '-logLevel')
        arg(value: 'INFO')
        classpath {
            pathelement(path:sourceSets.main.java.srcDirs)
            pathelement(path:sourceSets.main.output.resourcesDir)
            pathelement(path:sourceSets.main.output.classesDir)
            pathelement(path:sourceSets.main.compileClasspath)
        }
    }
           }

which does not work with no visible reasons why. Any clue?


(Luke Daley) #6

You’re launching the gwt process at configuration time, which means it’s going to be happening earlier than you think.

You need to wrap it in a ‘doLast {}’.


(Hariharan Thiagarajan) #7

Is there a update on this enhancement…