apache
Implement the wrapper as a single Java file using JEP 330
Implement the wrapper as a single Java file using JEP 330
crediting @hegyibalint, by coping:
- https://github.com/gradle/gradle/issues/35638
Expected Behavior
JEP 330 opened a new way of conveniently running a Java source file (e.g, java MySourceFile.java). We could use this mechanism to provide a readable entry point for how Gradle is launched.
When the wrapper would change—next to the SHA change—the textual, reviewable content of the wrapper could help users gain confidence that the changes can be trusted.
Current Behavior (optional)
The Gradle wrapper is a binary JAR. Checking binaries into repositories is often frowned upon, and considered not best practice. Despite this, Gradle chose to still go with this to provide convenience to the users; nowadays committing the wrapper became a widespread and accepted practice. We additionally have sha256 checksums for the wrappers, making sure the content is the same as expected.
However, the fact that the wrapper is a binary still poses some issues and friction with people. It's not easy to diff, and it's not easy to see what it does.
Context
There were several conversations about this, touching on these points:
- Don't make gradle-wrapper.jar a default part of a new project #25784
- Bootstrap Gradle build using cmd-line scripts only #11816
However, we believe this issue makes sense as a more exact way to improve the situation.
related to:
- https://github.com/google/error-prone/pull/5343
