[
https://issues.apache.org/jira/browse/OFBIZ-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870080#comment-16870080 ]
Jacques Le Roux commented on OFBIZ-10145:
-----------------------------------------
Hi Swapnil,
I thought about it again. Actually what are we doing when we upgrade Gradle in trunk? We update the gradlew scripts and the wrapper files, eg see [r1776532|
http://svn.apache.org/viewvc?view=revision&revision=1776532] and [r1848062|
http://svn.apache.org/viewvc?view=revision&revision=1848062].
With the Windows way that's all we need to do. Just update gradlew.bat in the trunk and the wrapper files in tools. A change must though be done in current gradlew.bat: the wrapper must always be copied over in trunk from the tools, somehow like in Buildbot. Not a big deal, we speak about 50 Kb. Like before, to use the latest version of Gradle, the user must SVN update his/her working copy.
There is only one drawback with this strategy, the user must have an Internet connexion. At some point it needs it: to SVN update the trunk. But later the connexion may be missing. A smal change in init-gradle-wrapper.ps1, [too catch the connexion error|
https://stackoverflow.com/questions/19122378/powershell-web-request-without-throwing-exception-on-4xx-5xx] is enough.
If the user did not run gradlew at the same moment than SVN updating, s/he must wait the next time a connexion is available to get the new Gradle version. In this case, I don't expect much issues with the possible but hopefully rare discrepancy between gradlew.bat and the wrapper.
What do you think?
> Remove the Gradle wrapper from our release packages and add a step to our build notes
> -------------------------------------------------------------------------------------
>
> Key: OFBIZ-10145
> URL:
https://issues.apache.org/jira/browse/OFBIZ-10145> Project: OFBiz
> Issue Type: Task
> Components: Gradle
> Affects Versions: 17.12.01, 16.11.06, 18.12.01
> Reporter: Jacques Le Roux
> Assignee: Nicolas Malin
> Priority: Blocker
> Fix For: 17.12.01
>
> Attachments: OFBIZ-10145-gradlew.patch, OFBIZ-10145_wrapper_properties_check.patch, gradlew.bat.patch, gradlew.bat.patch, init-gradle-wrapper-R16.sh, init-gradle-wrapper-trunk-and-18.sh, init-gradle-wrapper-trunk-and-18.sh, init-gradle-wrapper-trunk-and-18.sh, init-gradle-wrapper-trunk-and-18.sh, init-gradle-wrapper.ps1, init-gradle-wrapper.sh, init-gradle-wrapper.sh, init-gradle-wrapper.sh, init-gradle-wrapper.sh, init-gradle-wrapper.sh, init-gradle-wrapper.sh, init-gradlew-readme-R16.patch, init-gradlew-readme-R17.1.patch, init-gradlew-readme-R17.1.patch, init-gradlew-readme.patch, init-gradlew-readme.patch
>
>
> Following the discussion at
http://markmail.org/message/nd7grfiyobjkfwae, considering LEGAL-288 and based on a lazy consensus on dev ML, we want to remove the gradle-wrapper.jar file from the next packaged releases and use [~jacopoc]'s related proposition to document how to have Gradle working in the main README.md file.
> # Extract the archive file to your local directory.
> # Download gradle-wrapper.jar and place it in the OFBiz-root-dir/gradle/wrapper folder.
> I'm not sure if we should recommend a link to download the gradle-wrapper.jar. This might change in the future (versions, etc.), so indeed maybe simply asking to download is enough, cf
https://www.google.com/search?q=gradle-wrapper.jar+download&ie=UTF-8> Also we need to add a point about removing gradle-wrapper.jar in
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Locked
