Julian> Lastly, this .jar file is non-essential. The release builds just fine without it.
The use of consistent build tool versions would reduce risks. For instance: Maven 3.6.1-SNAPSHOT might happen to build Calcite "just fine" yet it could silently corrupt something. Then ./mvnw does not verify download integrity, so it makes build/release less secure. Why take those risks? How can I validate calcite.jar artifacts that are uploaded to Maven repository? Which tool could I use to validate that jars match the expected ones? Can I vote for source artifacts only and explicitly veto binary jars on a basis of "I can't validate wha's inside"? Even though Maven does not support wrapper natively, the case for wrapper would be even more important when we use Gradle. I see a couple of options: A) Include maven-wrapper.jar, and put its expected SHA256 side by side. We don't update the file often, so "IP and/or tampering" could be checked by verifying SHA for the jar file. B) We could include maven-wrapper in a source form and build it during the very first mvnw call. All the *.java files for maven-wrapper sum up to 70KiB which is just tiny. A single JdbcTest.jar is 350KiB. Any thoughts? ^^ The question above is quite real and I guess the answer would be pretty much reused for Gradle-based build. Julian> Since we have created them, and they are available nowhere else, they Julian> belong in the source release. I don't think we created fontawesome-webfont.ttf, did we? Technically speaking, calcite/site/fonts is 500+KiB which does look like binary files. Julian> Code is different. The textual source is editable, but the object Julian> files (in this case the .class files in the .jar) are not. As you know, "TrueType systems include a virtual machine that executes programs inside the font", so *.ttf is an object file. There are CVEs for TTF processing. Even though it might sound like a stretch, I don't quite buy "having consistent build system is not important" kind of conclusions. Vladimir
