[GRADLE-2466] Support specifying GRADLE_OPTS as part of Wrapper task Created: 06/Sep/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.2
Fix Version/s: None

Type: New Feature
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 3


From forum post:

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.

I tend to agree. I end up hacking this in to almost every project I work on.

Comment by Phil Webb [ 31/Oct/12 ]

Here is a workaround to set GRADLE_OPTS after the files have been generated:

def defaultWrapper = tasks["wrapper"]
task wrapper(overwrite: true, dependsOn: defaultWrapper) << {
    def gradleOpts = "-XX:MaxPermSize=1024m -Xmx1024m -XX:MaxHeapSize=256m"
    File wrapperFile = file('gradlew')
    wrapperFile.text = wrapperFile.text.replace("DEFAULT_JVM_OPTS=", "GRADLE_OPTS=\"$gradleOpts \$GRADLE_OPTS\"\nDEFAULT_JVM_OPTS=")
    File wrapperBatFile = file('gradlew.bat')
    wrapperBatFile.text = wrapperBatFile.text.replace("set DEFAULT_JVM_OPTS=", "set GRADLE_OPTS=$gradleOpts %GRADLE_OPTS%\nset DEFAULT_JVM_OPTS=")
Comment by Dan Stine [ 05/Dec/13 ]

Potential fix in PR 171.

Discussion on gradle-dev.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:22:41 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.