Never mind -- I answered my own question.
For posterity, simply setting the workingDir property in the closure looks
to work just fine.
def cmd = ["${javaHome}/bin/java",'-version']
project.exec {
commandLine = cmd
workingDir = new File("${rootDir}/build_scripts")
}
It's working like a champ! Thanks, again!
On Thu, Feb 10, 2011 at 12:30 PM, Bill Carlson <[email protected]> wrote:
> 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
>>
>>
>
