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
