Hi Adam,
My original understanding was that 'org.gradle.jvmargs' could only be employed if I explicitly use the daemon. This is per the userguide sentence "_Specifies the jvmargs used for the daemon process_". And I didn't want to commit to using the daemon on our build server, a sentiment echoed in the userguide sentence "_We don't run CI builds with the daemon (i.e. a long running process) as the CI environment is optimized for consistency and reliability_". Given your note below, I realized that when I specify 'org.gradle.jvmargs', Gradle forks a new JVM with main class 'org.gradle.launcher.daemon.bootstrap.GradleDaemon' anyway. Though it isn't a daemon in the sense of a reusable process, so I think this would alleviate the build server concern. However, it does feel cleaner to specify args via wrapper configuration. Then there is no need to fork a process if the daemon is not used. Nor would the "_To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon_" warning be displayed in such a case. There seems to be some support for this point of view in the forums [1], and also in the Spring framework [2] and Gradle itself [3]. Perhaps you prefer to err on the side of one-way-to-do-something, which is certainly valid. I guess if that's the case, maybe GRADLE-2466 should be closed as Won't Fix or otherwise updated? Dan [1] http://forums.gradle.org/gradle/topics/is_there_a_less_volatile_way_of_specifying_gradle_opts_for_gradlew_than_manually_adding_them_to_the_generated_script [5] [2] https://github.com/SpringSource/spring-framework/blob/14ac023e01226778b8481a54a657d3f7f6e5e36b/build.gradle#L990-L997 [6] [3] https://github.com/gradle/gradle/blob/7c1656c2c3d10d675add7c9b4f3ef945d94aa593/gradle/wrapper.gradle#L34-L43 [7] On 2013-07-12 17:28, Adam Murdoch wrote: > I'm not sure about this change. You should just use 'org.gradle.jvmargs' in > 'gradle.properties' instead. > > On 09/07/2013, at 11:44 AM, Dan Stine <s...@stinemail.com [3]> wrote: > >> Hello, >> >> I created a pull request [1] as a first attempt at addressing GRADLE-2466 >> [2], and I have a few questions about the approach. In particular, is it >> appropriate: >> >> * for the new property to be typed as List<String>? >> * for the new property to be named DefaultJvmOpts (instead of GradleOpts, >> perhaps) >> * to set DefaultJvmOpts on the script generator (instead of somehow actually >> setting GRADLE_OPTS itself) >> >> Other feedback also welcome, of course. >> >> Thanks, >> Dan >> >> [1] https://github.com/gradle/gradle/pull/171 [1] >> [2] http://issues.gradle.org/browse/GRADLE-2466 [2] > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org [4] > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com Links: ------ [1] https://github.com/gradle/gradle/pull/171 [2] http://issues.gradle.org/browse/GRADLE-2466 [3] http://issues.gradle.org/browse/mailto:s...@stinemail.com [4] http://www.gradle.org [5] http://forums.gradle.org/gradle/topics/is_there_a_less_volatile_way_of_specifying_gradle_opts_for_gradlew_than_manually_adding_them_to_the_generated_script [6] https://github.com/SpringSource/spring-framework/blob/14ac023e01226778b8481a54a657d3f7f6e5e36b/build.gradle#L990-L997 [7] https://github.com/gradle/gradle/blob/7c1656c2c3d10d675add7c9b4f3ef945d94aa593/gradle/wrapper.gradle#L34-L43
