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.
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
0
BUILD SUCCESSFUL
Total time: 3.828 secs
So now, the questions are:
- Has this functionality (capturing standard output from a subprocess) been
deprecated?
- Is there a mechanism for executing one task repeatedly with different
arguments in a thread pool?
- 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
>
>
