[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 |
Description |
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. |
Comments |
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:
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. |