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.