[GRADLE-1254] JavaExec Task should expose a way to execute java processes in the background. Created: 14/Dec/10  Updated: 08/Feb/17  Resolved: 08/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.9-rc-3
Fix Version/s: None

Type: Improvement
Reporter: Erick Dovale Assignee: Unassigned
Resolution: Duplicate Votes: 59


 Description   

Currently there is no natural way to execute a java process in the background. Here is a chat I had with merscwog in the IRC channel about this topic:

<edovale> any of you guys know how can I get the javaexec task not to wait for process termination before returning?
<merscwog> Not sure that it can be done right now. Adam would know for sure, but he's not on at the moment. Basically you would need something like the setDaemon() option that the JettyRun tasks have.
<merscwog> Presumably you want to join with the forked process sometime in a later task, or you just want to leave the forked process running until explicitly stopped.
<edovale> I will need to stop the process after the tests are done.
<edovale> Do you think a better approach could be to use the ant exec task?
<merscwog> I've used the built in groovy string execute() methods, or the standard Java ProcessBuilder and calling start() on that and handling the returned Process object later.
<edovale> Thanks, I'll look into that.
<merscwog> You also might consider filing a JIRA about enhancing the Exec task and JavaExec tasks to allow for running something in the background, and setting a Process object as part of the task that can be manipulated by a further task (to allow waitFor() and destroy())
<edovale> Are you then certain that it can not be done now?
<merscwog> No. I am not certain, but it delegates to a org.gradle.process.internal.DefaultJavaExecAction which only has one execute() method, and it has a waitForFinish() call directly before it checks to see if isIgnoreExitValue is set.
<merscwog> Hmm, I guess you could in theory simply override the javaExecHandleBuilder JavaExecAction object and do what you'd want.
<edovale> ok.. that sounds like certainty to me.. I could definetely overwrite the javaExecHandlerBuilder but the IMHO the task should expose this functionality in a more natural way. It doesn't seem to me this is an odd requirement.
<edovale> I'll file the jira issue..



 Comments   
Comment by Mauro Molinari [ 06/Dec/11 ]

Should be the equivalent of spawn=true in Ant Java task.

Comment by Luke Daley [ 07/Dec/11 ]

Related forum issue: http://forums.gradle.org/gradle/topics/does_javaexec_task_support_spawning_the_jvm_in_a_new_process_which_will_outlive

Comment by Pablo Munoz [ 21/Jun/12 ]

Are there any updates to this ticket? Can we include in 1.1 release?

Comment by Adam Murdoch [ 21/Jun/12 ]

@Pablo, it probably won't make it into the 1.1 release. We'll try and see if we can squeeze it in.

There are some pretty simple work-arounds:

  • You can use the Ant <java> task, with fork = true and spawn = true
  • You can use the JVM's ProcessBuilder to start the process (don't forget to close the process' stdin, stderr and stdout streams after you launch it).
  • You can use the Groovy execute() method, as a slightly more convenient way to start a process:

def process = ['java', '-cp', 'some-path', 'SomeMainClass', 'arg'].execute()
process.in.close()
process.out.close()
process.err.close()

Comment by Pablo Munoz [ 22/Jun/12 ]

Thank you Adam we'll try those out. Please keep us posted.

Comment by Davide Cavestro [ 06/Feb/14 ]

Any chance to get this fixed?
It would be great i.e. to launch GWT superdev mode within the IDE and still have its gradle integration available for other useful things (like dependencies resolution). Also switching the java execution code to ant calls is not so painless because of issues related to different classpath definition.

Comment by Endre Stølsvik [ 21/Feb/14 ]

I would really love this. This is now the second round of searching where I have this exact need.

Actually, what I also need, is the ability to fire off a process which spawns threads - and when the main-thread returns, I want the task to be finished. However, the threads run on in the background.

This is obviously going to be used for integration tests - whereby I start up e.g. a "self-contained Jetty" in a main method, and then when the application is up, the main method exits, and I can go for the tests.

Using ant.java, I can get this "when main method exits, the task is done" feature (by having both fork and spawn = false), but I ran into some other issues then (both that it runs within a restrictive security manager not e,g, allowing MBeans to be registered)..

Also using the ant.java, I can spawn it totally, but then I both loose the standard output, and I would need to implement some shaky polling strategy to check if the thing has come up. (Full fork/spawn/disown is also very good in itself - to e.g. on command line do a full build and then spawn the result - and exit Gradle. But when I need the spawn to just exist for the duration of the rest of the build, to interact with it from the rest of the build script for testing, the full fork is not the right solution.)

Comment by Frederic [ 27/Aug/15 ]

https://plugins.gradle.org/plugin/com.wiredforcode.spawn

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 08/Feb/17 ]

The issue is now tracked on GitHub: https://github.com/gradle/gradle/issues/1367

Generated at Wed Jun 30 11:50:52 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.