Is the use of the daemon the only reason that JVM properties can't be effectively set on the gradle command line?


(davidmichaelkarr) #1

I have in some of my notes while absorbing Gradle information that “JVM properties can’t be set on the command line”. It appears to me that this would be the case if the daemon was being used (or at least, you couldn’t guarantee they would be used). Is that the only situation that prevents the usage of JVM properties set on the gradle command line?


(René Groeschke) #2

you can use the -Dprop=val syntax in gradle as known from Java to pass system properties to your build via commandline. Not sure where your notes come from. This should work with and without the usage of the daemon


(davidmichaelkarr) #3

So you’re saying that if the daemon has already been started, and you run a new Gradle command line adding “-Dfoo=bar”, then if I were to connect to the daemon process, I would then find a “foo” system property? In general, I would assume this is false.

However, I did notice the following statement in the User Guide:

We fork a separate daemon process if the jvm arguments for the build are sufficiently different. For example we will not fork a new daemon if a some system property has changed. However if -Xmx memory setting change or some fundamental immutable system property changes (e.g. file.encoding) then new daemon will be forked.

So it appears that if Gradle sees some particular system property changes on the command line, it will restart the daemon.

On that subject, how do you set '-Xmx" properties on the Gradle command line? Perhaps this is the limitation I had noted.


(René Groeschke) #4

-Xmx is a java flag and not a system property. To set these flags for Gradle use GRADLE_OPTS environment variable or the org.gradle.jvmargs property in the gradle.properties file.

System properties in java and in gradle are passed using the -D command