[
https://issues.apache.org/jira/browse/OFBIZ-10145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867505#comment-16867505
]
Jacques Le Roux commented on OFBIZ-10145:
-----------------------------------------
I can get the wrapper and its properties from
https://github.com/gradle/gradle/tree/v5.0.0/gradle/wrapper and
https://github.com/gradle/gradle/tree/v3.2.1/gradle/wrapper. But not
https://github.com/gradle/gradle/tree/v2.13/gradle/wrapper. As often external
services have an end. That's one of the reasons I copied our files in tools.
After bad experiences (yes you GoOgle) I don't trust much external services
life durations. I can find it at
https://repo.spring.io/plugins-release/org/gradle/gradle-wrapper/2.13/gradle-wrapper-2.13.jar
but not the properties. Anyway I can't see how it's better than having our own
files copied somewhere. We need to change things when upgrading Gradle anyway.
Copying 2 files is not that much work.
Also, thinking about it, we only need my tools solution for Buildbot. Because
there all start afresh. So the wrapper is missing each time. But not Gradle,
it's there (with different versions) on the Builbot servers. That's why the
wrapper, and only it, should be copied from tools. On the demo we should use
init-gradle-wrapper.sh as in other environments (dev, production, etc.). Only
Buildbot is a transient environment that we have to handle specifically.
So rather than relying on an external service which can disappear in future, I
stay with my proposition. :)
I don't think we have a wiki page about "How to upgrade Gradle". I think we
need one now and I will create it, notably for the tools update thing.
> 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, 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)
