Hi,
We now have a few places where you can specify settings that affect the build:
* $rootDir/gradle/wrapper/gradle-wrapper.properties, can specify the Gradle
version to use (in the form of a Gradle distribution)
* $rootDir/gradle.properties, can specify the JVM args to use and whether the
daemon should be used (this is just new)
A user can also use ~/.gradle/gradle.properties to override the settings from
$rootDir/gradle.properties.
There are a few new settings that we (might) want to add at some point soon:
* The version of Java that the build requires.
* The location of the Java install (ie the java home dir) to use, as an
alternative to the version.
* The version of Gradle to use, as an alternative to the distribution URL.
* The location of a bootstrap init.gradle to use.
We also want to get rid of gradle-wrapper.properties, so that the Gradle
distribution URL and/or Gradle version goes to live with the other settings.
One question is whether gradle.properties is the appropriate place for these
settings. Hans pointed out that these settings play a different role to those
usually found in gradle.properties. Gradle version, JVM settings, and so on,
are the responsibility of the build master who owns the build infrastructure,
whereas gradle.properties is generally used for the build user to provide
inputs into the build. So, it might make sense to split these up.
One question is what this file should be called. Given the motivation for
splitting out these settings, it would make sense if the file did not live in
$rootDir. I can see a few options:
* In the existing $rootDir/gradle directory, eg
$rootDir/gradle/build.properties (thats $rootDir/gradle, not $rootDir/.gradle)
* In a new hidden directory, eg $rootDir/.gradleconf/build.properties
* As a hidden file, eg $rootDir/.gradleconf.properties
* In the existing $rootDir/.gradle directory, so as to be consistent with the
contents of ~/.gradle.
It's a bit of a 'what colour should the bike shed be?' question. My preference
is for $rootDir/gradle/build.properties, but only just.
Another question is what format the file should have. Properties are easy, but
it might be nice to have some structured info in there. Perhaps xml or json
would be a better option.
We could, if we put a little effort into it, even use a .gradle script of some
kind (possibly even an init.gradle script). Here's how it would work:
If in daemon mode:
- If no daemon running, launcher executes the scripts and starts the daemon
with the resulting configuration.
- If any daemons running, the launcher connect to the most-recently-used daemon:
- The daemon executes the scripts and compares its configuration with the
desired configuration.
- If the configurations match, execute the build.
- If the configurations do not match, reject the build, returning the
desired configuration for the launcher to start a matching daemon.
This way, there's no overhead when the configuration has not changed since the
daemon was last used, and a small overhead when it has.
If not in daemon mode:
- The launcher checks whether the config script(s) exist. If so:
- suggest to the user that they might prefer to use the daemon, and here's
how to enable it
- execute the scripts and compares its configuration with the desired
configuration
- if the configurations match, execute the build
- if the configurations do no match, fork a worker process with the desired
configuration, which will run the actual build.
- If there are no config scripts, run the build.
This way, there's no overhead if you want to use the defaults, and a workaround
for the overhead when you want to use something other than the defaults.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
