[
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)
