Is there a less volatile way of specifying GRADLE_OPTS for gradlew than manually adding them to the generated script files?


(Jörn Huxhorn) #1

I’m trying to commit project specific GRADLE_OPTS for gradlew/daemon into our VCS.

If I’m not missing anything, the best way to currently achieve this is by manually adding them as DEFAULT_JVM_OPTS in both gradlew and gradlew.bat.

But this has the severe downside that those changes will be overwritten whenever the wrapper task is executed. (I never edit the gradle-wrapper.properties manually. I always set the new version in the wrapper task and re-execute it.)

Shouldn’t it be possible to either specify the defaultJvmOpts in the wrapper task or load those values from a file that is not created or overwritten by the wrapper task but loaded by the start scripts?

I’d prefer configuration of the wrapper task.


(Peter Niederwieser) #2

Have you seen Configuring the build environment via gradle.properties?


(Jörn Huxhorn) #3

I really missed that part in the guide even though I knew from Hans that something like this exists. Sorry about that. I was indeed looking for this.

I read “Chapter 54. The Gradle Wrapper” as well as the documentation of the Wrapper task but failed to find that information or some link to it.

Wouldn’t such a defaultJvmOpts task property make sense anyway? There is a place in the script files for such options but there is no way to specify the contents other than editing the files.

My problem is that we have done a manual multi-multi-module-project and I assume (from looking at the documentation) that gradle.properties is only searched in the build directory but not above. Seems like I need to duplicate the gradle.properties file for every multi-module project in the multi-multi-module-project construct.


(Peter Niederwieser) #4

Maybe your case is special, but usually you’d have just as many wrapper task definitions as ‘gradle.properties’ files (namely one per build), so the effort of maintaining JVM arguments would be the same in both cases. And in ‘gradle.properties’, this information is available to a wider audience (e.g. tooling API) than if it’s hardcoded into the startup script.

It sounds like what you really need is out-of-the-box support for multi-multi-projects. This is something that’s on our longer-term roadmap.


(Jörn Huxhorn) #5

We only have one wrapper task definition in a company-wide defaults.gradle file that is included into all our other (multi-module-)projects. So whenever a new version of Gradle is released one developer updates the global file and builds everything, fixing any new issues and deprecation warnings and removing previously necessary workarounds. We don’t want multiple Gradle versions in active use simply because someone forgot to update his wrapper task or something like that.

I don’t know how the daemon is handling stuff like jvmArgs. Wouldn’t it need to be stopped and restarted if projects would request different jvmArgs? I assumed that it makes sense to keep those the same across multiple projects.

You are probably right about the multi-multi-projects. We are already waiting for those and this is part of our current workaround until this gets addressed.

But beside providing a possibly better solution in the future don’t you think that adding this as a wrapper task configuration option wouldn’t hurt? The tooling API could derive that info from the wrapper task configuration.

I explicitly don’t want to manually hardcode this into the scripts. I’d like to have those args generated into the scripts by the wrapper task.

We considered post-processing the scripts ourselves by extending the wrapper task but I thought that this could be of general use and wanted to suggest it here before investing my time into a private solution.


(Luke Daley) #6

I raised GRADLE-2466 for this, as we use this ourselves in our build. You can take the code from there:

https://github.com/gradle/gradle/blob/master/gradle/wrapper.gradle#L28


(Jörn Huxhorn) #7

Awesome, thanks!