A last thing that you pointed to in OFBIZ-10145 Swapnil.
Security issue with a Gradle version used in an already released package.
Like with other security issues we have no other way than letting the user
upgrade OFBiz.
So we don't need to "allow imperceptible Gradle upgrade".
Then the connexion to get the wrapper is only once during the installation, the
scaling issue is peanuts.
I trust we all agree to keep the wrapper in the trunk. It's not an issue there.
We can revert the changes we did in trunk.
It's only a RM issue. It's when packaging that we are tying OFBiz code with a
Gradle version.
It's only then that we need to modify the gradlew script, to call an
init-gradle-wrapper script if the wrapper is missing.
What do you think folks? Notably you Jacopo, with your RM hat on?
Jacques
Le 01/07/2019 à 13:36, Swapnil M Mane a écrit :
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 <[email protected]>
wrote:
Le 01/07/2019 à 06:53, Jacopo Cappellato a écrit :
On Sun, Jun 30, 2019 at 5:31 PM Mathieu Lirzin <
[email protected]>
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
