Hi all, I write here to avoid polluting the gradle developers thread: I’ve seen gradle guys are discussing about a way to set JVM options for the daemon VM (really needed, see http://gradle.1045684.n5.nabble.com/Setting-JVM-options-for-daemon-VM-td5041975i20.html ). That makes me think we often also need a way to control gradle JVM options (http://gradle.1045684.n5.nabble.com/Is-there-any-way-to-pass-gradle-JVM-options-from-command-line-without-GRADLE-OPTS-env-var-td4912969.html) but we can do it only using an environment variable of modifying the gradle wrapper script.
Wouldn’t it be good if the gradle launch would be structured in stages, where the 1st stage is a JVM process that possibly collects some data in order to properly launch the actual gradle JVM and its daemon? This way the 1st stage could: - access every kind of configuration through raw properties files, groovy (config slurper), gradle ad-hoc dsl file (in the gradle work dir or specified from CLI/env var), ini4j, java preferences api and so on (there could be an ecosystem of gradle plugins here) - launch the gradle JVM and its daemon with proper options (separate stages?)
Please note that if the 1st stage can access groovy/gradle code, we could also provide some heuristics or at least use some conditional statements in order to produce properly JVM configuration options. Granting access to well-known configuration facilities (ini4j, java preferences) would also give the opportunity to use some GUI tools to write them.