I am new to Gradle and Gradle Wrapper and I am confused about what Gradle Wrapper does.
As stated in the official website, there are two benefits from Gradle Wrapper:
Standardizes a project on a given Gradle version, leading to more reliable and robust builds.
Provisioning a new Gradle version to different users and execution environment (e.g. IDEs or Continuous Integration servers) is as simple as changing the Wrapper definition.
which I agree.
However, as I see it, we do not need a new thing (Gradle Wrapper) to gain these benefits. A simple script could do the same thing, something like this
# 1. download Gradle zip file of specific version
# 2. unzip the downloaded file to specific location (e.g., ~/.gradle/wrapper)
# 3. activate the gradle using environment variable (adding new gradle executables to PATH)
With this script, I believe we can do anything that Wrapper does.
I haven’t found a convincing answer for this, really appreciate if someone could share some insights.
So you are suggesting to not use the wrapper but instead write an own script that does exactly the same thing?
Because that is basically what the wrapper is doing.
It downloads a specific version of Gradle to the cache, optionally verifies its checksum, and then uses this downloaded version to execute the build.
Some advantages of the standard wrapper opposed to you writing an own script that does the same things are:
it is thoroughly tested through extremely widespread use, as 98,7 % of the Gradle projects out there use it and any that does not imho has a bug
every Gradle user knows it and is familiar with it
Gradle users can trust it by verifying the checksum to ensure it is the standard wrapper
downloaded versions can be reused across projects as the wrapper is a standard building block
I agree all the advantages that you mentioned. If the mentioned script and Gradle Wrapper are doing the same thing, the simple one should be adopted, right ? In this case, Gradle Wrapper seem a bit complex to me in two aspects.
It introduces extra gradle-wrapper.jar and gradle-wrapper.properties, why is another jar involved ?
It replaces original gradle binary with gradlew, which is kind of confusing and unnecessary.
I don’t fully agree.
The gradlew script is made as compatible as possible, it is sh compatible so should run anywhere sh is available, not using any bash specifics or similar.
Also Some things are just easier to implement, review, etc. if you can do it in Java, opposed to a plain sh script.
If you do all in the script, then some things are not possible easily, like for example calculating the checksum which then again needs tools that have to be installed at the system where the script should run and so on.
That gradle is replaced by gradlew is imho not really confusing except maybe for a total Gradle newcomer, because almost anyone using Gradle before is familiar with the wrapper.
Most people using Gradle don’t even have Gradle installed on their system which also is an advantage of the wrapper.
So most people don’t even have a gradle executable.