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
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
