Hi Mathieu, Nicolas,
@Mathieu, I disagree. IMO this is part of the release process and can be
handled by the RM (Release Manager).
When releasing, all the RM has to do is to verify the version in the wrapper is the right one. It it's not, s/he must upgrade Gradle locally and save
the wrapper files in tools.
This saving must be done just after the upgrade. Else the local wrapper files will be overwritten by the ones in tools at the next use of the gradlew
script (yes, I got caught by that :/).
There should be trivial side effect in gradlew scripts due to the Gradle upgrade. Currently only the test on wrapper presence in
init-gradle-wrapper.sh and the ASL2 license header are removed.
It's only one block, easy to put back from repo. This will be documented for
the RM as mentioned in OFBIZ-10145.
I'm not the release manager but all committers can do the same for the trunk.
And that's what I did.
After applying the last waiting gradlew.bat.patch in OFBIZ-10145 I was able to
follow this way.
BTW, I was mislead by Gradle versions names in URL (sometimes?) inconsistent.
You have
https://github.com/gradle/gradle/tree/v5.5.0/gradle/wrapper (5.5.0) (used as
RELEASE value in init-gradle-wrapper.sh)
but
https://services.gradle.org/distributions/gradle-5.5-bin.zip (5.5)
So to update Gradle it's
|gradlew wrapper --gradle-version=5.5 --distribution-type=all|
not
gradlew wrapper --gradle-version 5.5.0|--distribution-type=all|
All is better for IDE, default is bin[1].
@Mathieu, I found a trivial issue in your last commits and fixed it: repeated
"-Xms64m" in gradlew scripts.
@Nicolas, the version of init-gradle-wrapper.ps1 you committed used HTTPS. I have changed that to HTTP, not everyone has an HTTPS access to the tools
repo.
Anyway, using the last command worked for me on Windows.
I committed the trunk and tools changes.
[1]
https://mrhaki.blogspot.com/2016/09/gradle-goodness-specify-wrapper-version.html
Jacques
Le 30/06/2019 à 17:31, Mathieu Lirzin a écrit :
Hello Nicolas,
Nicolas Malin <[email protected]> writes:
I would had tend to be agree with you with the first step done.
At this time, only [curl,wget] is necessary, and download realease at
the fisrt gradlew command call.
‘grep’ and ‘whereis’ are currently needed in a Unix environment too. ;-)
We take the jar, put it directly at the good place and continue the job.
Unfortunately this is not that simple. Here are two important
requirements that the current version of “init-gradle-wrapper.sh” is not
handling:
1) The integrity of downloaded jar must be checked (via
checksum). This is important both for reliability and security
reasons. If we don't do that our users are vulnerable to DNS
spoofing.
2) The downloaded jar needs to be automatically upgraded. Currently
when committers are upgrading Gradle (like I just did in revision
1862326) the users must delete their “gradle-wrapper.jar”
manually to not keep using their local outdated version which
might be incompatible.
In fact the more I think about the problem we are trying to solve, the
more I am convinced we should not try to write our own additional layer
of build system which if done seriously will lead to complex code.
Gradle wrapper is suppposed to be a convenience both for maintainers and
users to facilitate the use of a single and consistent version of
Gradle. IMO with the requirement of not distributing
“gradle-wrapper.jar” in our releases this is becoming a burden for
maintainers and an unreliable solution for users.
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
