Is it possible to have the project.exec run from a specific directory? project.exec() worked great in my test, so I'd like to try it in my full build, but I need to run the processes from a subdirectory. Obviously,there are ways around it, but the way we're doing it right now is using the List method *execute<http://groovy.codehaus.org/groovy-jdk/java/util/List.html#execute(java.util.List, java.io.File)>*(List<http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html> envp, File <http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html> dir) to execute.
And thanks for being so responsive! This has been fantastically helpful. On Thu, Feb 10, 2011 at 3:34 AM, Adam Murdoch <[email protected]> wrote: > > On 10/02/2011, at 11:27 AM, Bill Carlson wrote: > > I like the idea of creating a task for it, but I'm not sure how it would > work -- we are using the execute() method to run multiple large and long > running regression tests in a multiple separate JVMs in a thread pool. We > also have some post-processing that needs to be done after each individual > run has completed. > > > There are equivalent exec() and javaexec() methods on Project which you can > use instead of the task types. They work the same way: > > project.exec { > commandLine = [...] > } > > project.javaexec { > main = 'some.class' > classpath = someClasspath > } > > > > The main bit of interest is that it worked in 0.9-rc-1, but not in 0.9.1. > JAVA_HOME is defined and the waitFor() is returning 0. I modified the test > to the following: > > task testOutput << { > String javaHome = System.env['JAVA_HOME'] > println(javaHome) > Process p = ["${javaHome}/bin/java",'-version'].execute() > p.consumeProcessOutput(System.out, System.err) > println(p.waitFor()) > } > > > And got the following: > > 0.9-rc-1: > > D:\temp>\gradle-0.9-rc-1\bin\gradle testOutput > :testOutput > C:\PROGRA~1\Java\JDK16~1.0_1 > java version "1.6.0_17" > Java(TM) SE Runtime Environment (build 1.6.0_17-b04) > Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing) > 0 > > > > 0.9.2 (same behavior as 0.9.1): > > D:\temp>\gradle-0.9.2\bin\gradle testOutput > :testOutput > C:\Program Files\Java\jdk1.6.0_17 > > > I wonder if the different value for JAVA_HOME is causing grief (eg the > space). You could try hardcoding the old value for JAVA_HOME in the script > and trying it with 0.9.2. > > > 0 > > BUILD SUCCESSFUL > > Total time: 3.828 secs > > So now, the questions are: > - Has this functionality (capturing standard output from a subprocess) been > deprecated? > > > No. It is still supposed to work. > > > > - Is there a mechanism for executing one task repeatedly with different > arguments in a thread pool? > > > No, but you can use the exec() or javaexec() methods in a thread pool, if > you like. > > At some point we will add the ability to run tasks in parallel. We probably > won't add the ability to run the same task multiple times. However, you will > be able to create a dynamic set of tasks, each with its own arguments - so > pretty much the same thing. > > > - Or, would it be easier to write a plugin for this sort of behavior? > > Thanks! > -=b=- > > On Wed, Feb 9, 2011 at 4:56 PM, Adam Murdoch <[email protected]> wrote: > >> >> On 10/02/2011, at 6:39 AM, Bill Carlson wrote: >> >> Hi, everyone! Unfortunately, my introduction to this list has to be due >> to an issue we are having. >> >> We started using Gradle with 0.9-rc-1. We have a number of regression >> tests that are executed as subprocesses from a main gradle script, and >> everything was working great -- it was a vast improvement over either the >> Ant or Maven builds we've previously run. However, we recently upgraded to >> 0.9.1 (and have also tried 0.9.2 and the latest code from the git repository >> for that matter), and we no longer get the System.out from the subprocess. >> >> As a test, I created the simplest build.gradle I could think of to show >> the error: >> >> task testOutput << { >> String javaHome = System.env['JAVA_HOME'] >> Process p = ["${javaHome}/bin/java",'-version'].execute() >> p.consumeProcessOutput(System.out, System.err) >> p.waitFor() >> >> >> It might be worth checking that waitFor() is returning 0, rather than some >> error status code. Also you could check that 'JAVA_HOME' is set to >> something. >> >> Another option is to try using the Exec task, to see if that offers any >> clues: >> >> task testOutput(type: Exec) { >> String javaHome = ... >> commandLine = ["${javaHome}/bin/java', '-version'] >> } >> >> This defaults to writing to System.out and System.err. See >> http://gradle.org/0.9.2/docs/dsl/org.gradle.api.tasks.Exec.html for more >> details. >> >> Or you could try the JavaExe task: >> >> task testOutput(type: JavaExec) { >> main = 'some.class.name' >> } >> >> This defaults to using the java executable for the current jvm. See >> http://gradle.org/0.9.2/docs/dsl/org.gradle.api.tasks.JavaExec.html for >> more details. >> >> >> } >> >> >> On my Linux system (Fedora 13), I get the following: >> >> bcarlson@bcarlsondt:~/tmp$ gradle testOutput >> :testOutput >> java version "1.6.0_17" >> Java(TM) SE Runtime Environment (build 1.6.0_17-b04) >> Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode) >> >> BUILD SUCCESSFUL >> >> Total time: 7.396 secs >> >> >> This works great, just as I would expect. However, on our main build >> machine, which is Windows Server 2008 SP2, I get the following (with the >> exact same build.gradle) >> >> D:\temp>gradle testOutput >> :testOutput >> >> BUILD SUCCESSFUL >> >> Total time: 15.931 secs >> >> >> And, when running the "java -version" command from the command line, I get >> the following: >> >> D:\temp>java -version >> java version "1.6.0_17" >> Java(TM) SE Runtime Environment (build 1.6.0_17-b04) >> Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing) >> >> >> So, I'm using the same JDK, with the only difference being 32-bit on the >> Windows machine, and 64-bit on the Fedora machine. These were both executed >> with a clone of the git repository as of about 10:00 EST today. >> >> In searching the archives, the only thing I could find that I thought >> might even be related was GRADLE-1252, which refers to TestNG output. >> >> Does anyone have any ideas on this? >> >> Thanks! >> -=b=- >> >> Bill Carlson >> >> >> >> >> >> >> -- >> Adam Murdoch >> Gradle Developer >> http://www.gradle.org >> CTO, Gradle Inc. - Gradle Training, Support, Consulting >> http://www.gradle.biz >> >> > > > -- > Adam Murdoch > Gradle Developer > http://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consulting > http://www.gradle.biz > >
