On 03/12/2011, at 1:20 AM, Peter Niederwieser wrote: > Hi, > > we now have basic support for setting JVM options for the daemon VM. > Initially I wanted to reuse the GRADLE_OPTS environment variable so that > this variable would take effect for whichever VM actually runs the build. > However, it's not easy/desirable to figure out from the client VM's startup > script whether the build runs in daemon mode or not.
That's not necessarily a problem. We could use GRADLE_OPTS for both until the daemon is enabled by default, then stop using GRADLE_OPTS for the client jvm. > Hence I've introduced > another environment variable GRADLE_DAEMON_OPTS that just takes effect for > the daemon VM. > > What do you think about this solution? Do you have a better idea? I'm keen to have a solution that works (in the longer term) regardless of whether the daemon is involved or not. So, the name 'GRADLE_DAEMON_OPTS' doesn't really work. Perhaps we should use something other than environment variables as the primary way to do this, leaving environment variables as a fallback (or get rid of them entirely). The final goal is to have this stuff declared in the build somewhere, checked into the source tree, so you can just checkout and build without needing to mess with jvm args. So, one option is to use a config file in the build itself: 1. Use gradle.properties, with some well-known properties. 2. Use gradle-wrapper.properties, so that it lives with the declaration of which Gradle version to use (ie this file becomes a declaration of the dependencies of the build itself. Could also end up with a Java version constraint here too). 3. Some other config file. I like option 2, given that we want to use the wrapper more and more, and that the tooling API will be easily able to make use of this. We might also have a corresponding entry in ~/.gradle/gradle.properties, too, so you can do a local override. > > Another question is whether we should set a default for GRADLE_DAEMON_OPTS, > in particular with regard to memory settings. Currently we don't, just as we > don't set a default for GRADLE_OPTS. I'm a bit hesitant to add a "hidden" > default. Maybe it's better for memory settings to be configured explicitly > (or fall back to JVM defaults). I think the default are usually a bit small in practice, and we want something a little more generous. Another problem is that the jvm defaults are not that portable, so that a build that works on one person's machine may not work on another. But, if we make it possible to specify the jvm args (or at least heap sizes) in the build, then maybe this is not a problem. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
