Pankraz76 opened a new issue, #385: URL: https://github.com/apache/maven-wrapper/issues/385
### New feature, improvement proposal crediting @hegyibalint, by coping: - https://github.com/gradle/gradle/issues/35638 ### Expected Behavior [JEP 330](https://openjdk.org/jeps/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](https://github.com/gradle/gradle/issues/25784) * [Bootstrap Gradle build using cmd-line scripts only #11816](https://github.com/gradle/gradle/issues/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 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
