Julian>2. Regarding gradle-wrapper.jar. Yes, it affects Calcite too Removal of gradle-wrapper.jar creates problems, and it solves no real issues.
Just in case, if you are to forbid binary files in the source release, then please clarify why do you allow the following binary files in the source release: /favicon.ico /site/img/feather.png /site/img/logo.png /site/js/html5shiv.min.js /site/js/respond.min.js ^^^ the above is not a joke. The files are binary, it is hard to verify if they contain backdoors or security issues. I literally can't tell if logo.png could hack a preview app in my OS. I can't re-create logo.png from text-like human-readable sources. Forsing users to do download Gradle manually makes it way harder to build Calcite (they would have to track the exact version). Even in the case users would download the proper Gradle version manually, they might miss verifying the integrity, so removal of gradle-wrapper.jar opens a possibility for supply-chain attacks (currently the wrapper is verified, and it verifies the retrieved Gradle). Automatic retrieval of gradle-wrapper.jar is hard to do in a secure manner. In case you missed it, Maven Wrapper did NOT verify the retrieved jar. At the same time, gradle-wrapper.jar can be verified: 1. There are the official checksums 2. Users can build their own gradle-wrapper.jar (e.g. from Gradle sources) and ensure the resulting jar matches exactly what is included in the release In other words, the inclusion of gradle-wrapper.jar makes it significantly more secure and easier to operate for the consumers. The ones who have a fear of jar files can unpack tar.gz and delete all the jars if any. Julian> My opinion is that neither the release plugin (nor the release manager) should be modifying source files. What do you suggest for the case when binary and source releases have different contents due to a different set of the embedded third-party dependencies? Vladimir
