Thanks, this indeed did the trick. Before I got your answer, I had converted my custom tasks into a plugin in a 'flat directory' repository. this also has the nice impact of speeding the build a little.
Jp On Mon, Nov 14, 2011 at 8:31 PM, Peter Niederwieser <[email protected]>wrote: > The compileJava task runs in-process by default, so I don't think the > memory-related compiler args will take effect. Instead, try to set -Xmx in > GRADLE_OPTS (not JAVA_OPTS). > > The compileGroovy task runs in a separate process by default. Try this in > buildSrc/build.gradle: > > tasks.withType(GroovyCompile) { > groovyOptions.forkOptions.memoryMaximumSize = "256m" > } > > -- > Peter Niederwieser > Principal Engineer, Gradleware > http://gradleware.com > Creator, Spock Framework > http://spockframework.org > Twitter: @pniederw > > > > jean-philippe robichaud wrote: > > > > Hi, > > > > I'm really stuck: we're using gradle in the Sun Grid Engine environment. > > Recently, some change in the grid configuration changed (I'm not sure > > what, > > I'm not close to the admins) and now java has trouble just "starting": > > "java -version" fails with "cannot allocate enough heap memory"... > > > > I discovered that launching the jvm with "-client" seems to do the trick > > *but*, we have a set of custom gradle tasks in our build system and when > > they need to be recompiled, I'm getting this error again. > > > > JAVA_OPTS is set to "-client -Xmx128m -Xms32m", but that doesn't help. > > > > I tried putting this in my build.env: > > > > tasks.withType(Compile).all { > > options.compilerArgs << '-Xms32m' << '-Xmx128m' << '-client' > > } > > > > but that seems to be interpreted *after* gradle tries to compile the > > custom > > tasks. > > > > The stacktrace I get looks like this: (running with Gradle 1m5 on sun jdk > > 64bit ): > > > > 13:52:49.512 [DEBUG] > > [org.gradle.api.internal.project.ant.AntLoggingAdapter] > > Execute:Java13CommandLauncher: Executing '/gpfs/scratc > > '-classpath' > > > '/gpfs/scratch01/data/zbcdef/scratch/jrobicha/bbnnbbnn/opt/gradle-1.0-milestone-5/lib/logback-classic-0.9.29.jar:/gpfs/scratch01/da... > > '-Dfile.encoding=UTF-8' > > 'org.codehaus.groovy.tools.FileSystemCompiler' > > '--classpath' > > > '/gpfs/scratch01/data/zbcdef/scratch/jrobicha/zzz/opt/gradle-1.0-milestone-5/lib/logback-classic-0.9.29.jar:/gpfs/scratch01/data/zb... > > '-j' > > '-Fg' > > '-Jsource=1.5' > > '-Jtarget=1.5' > > '-d' > > > ''/.local/work/history/build.jrobicha.2011-10-30_12_00_b/DS2_wc/build/buildSrc/build/classes/main' > > > '/.local/work/history/build.jrobicha.2011-10-30_12_00_b/DS2_wc/build/buildSrc/src/main/groovy/com/zzz/yy/build/CustomTask1.groovy' > > > '/.local/work/history/build.jrobicha.2011-10-30_12_00_b/DS2_wc/build/buildSrc/src/main/groovy/com/zzz/yy/build/CustomTask2.groovy' > > > '/.local/work/history/build.jrobicha.2011-10-30_12_00_b/DS2_wc/build/buildSrc/src/main/groovy/com/zzz/yy/build/CustomTask3.groovy' > > > > as you can see, there isn't -client or other jvm options passed there. > > > > Is there a way I can tell gradle to use these jvm option for compiling > the > > groovy custom tasks? > > > > Or even better: any clue why java would die so quickly (even just "java > > -version")? > > > > This is really impacting our ability to work properly! > > > > Thanks for your help! > > > > Jp > > > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/passing-parameters-to-java-for-buildSrc-compileGroovy-task-tp4992076p4993109.html > Sent from the gradle-user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
