Thanks, everyone for sharing your kind thoughts. I am also inclined towards allowing users to follow the standard Gradle installation process.
We tried our best to make the user's life easier by avoiding their intervention in downloading respective Gradle (resulting the changes in gradlew and gradlew.bat files and writing init-gradle-wrapper script), but, it seems this will brings various complexities and maintenance issues to us like -- Upgrading the Gradle version -- Distribution of the wrapper jar So IMO, let's keep things simple and let the users follow standard Gradle installation. Best Regards, Swapnil M Mane, ofbiz.apache.org On Mon, Jul 1, 2019 at 1:52 PM Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Le 01/07/2019 à 06:53, Jacopo Cappellato a écrit : > > On Sun, Jun 30, 2019 at 5:31 PM Mathieu Lirzin < > mathieu.lir...@nereide.fr> > > wrote: > > > >> [...] > >> As a consequence, I would recommend keeping the wrapper jar in our VCS > >> repository, and simply remove it along side the “gradlew” scripts from > >> our release archives. We would then provide preliminary build > >> instructions stating the required version of Gradle and let users choose > >> how they want to install it [1]. > >> > >> [1] https://docs.gradle.org/current/userguide/installation.html > > > > I tend to agree with Mathieu. > > The above approach would also cover another concern I had with some of > the > > proposals: since release files can be downloaded by a potentially large > > number of users, they must be distributed thru the mirror network [*]; > > distributing the wrapper jar from our svn, git or website would not scale > > up well and could cause excessive load on these server. > > > > Jacopo > > > > [*] https://www.apache.org/dev/release-distribution > > After working on a Buildbot solution, I suggested this way because I > thought it would be easy for our users, and maybe our own tranquillity. > > I did not think about scaling. We speak about 55 Kb, the connexions would > be very short, so not much at the same time. > > It started from this Mark Thomas's remark in LEGAL-288: > > <<The JARs are small and will be downloaded as part of the source tree > so I don't think Infra would have any objections.>> > > Though with my last proposition, to allow imperceptible Gradle upgrade, > this download would be for each call to OFBiz gradlew anywhere. That's > indeed > something to consider. > > Nicolas suggested to get the wrapper from Git. That can be done, but needs > a solution when it disappears there. And it's maybe not fair to them. > > I agree, the easiest way for us is certainly to let users follow the > standard Gradle installation process as they do for Java. > > I'm not against that, just another step that we tried to avoid to our > users and their customers. > > For working copies checked out (including Buildbot and demos) we can keep > the wrapper where it is. > > Following LEGAL-288, that's what I initially described in OFBIZ-10145. It > was a nice tour :) > > Can we conclude? > > Jacques > > >
