Hi Everyone, James F & I have been discussing the ASF release process. I've previously mentioned that we have to have reproducible builds to use GitHub actions. We have made the discovery that it's impossible to have reproducible builds in forge due to this bug: https://github.com/oracle/graal/issues/291 Moreover, upon investigation, the shipped binary size of the grails-forge-cli is 81mb. The jar files are only 40mb. For this reason, we want to propose we ship the jar files instead to be compliant with Apache's requirements.
With that said, what follows is what we've found & what we want to change so that we have: 1. reproducible builds 2. flexibility to call either forge or shell 3. keep shipped binary sizes to a minimum (bandwidth saving) My thought process follows, and a set of requirements to implement what we need to achieve these calls. Please review and provide feedback. Thoughts & Proposal: ------------------------------------------------------ * Following project structures today: 1. Single Project 2. Multi Project Grails Builds 3. Multi Project Mixed Framework Builds * a `Grails` shell script has to be at the root - executing that shell script needs to divert to either the grails-shell-cli or the grails-forge-cli - alternatively we can have a basic application that passes through to either of them * How to find the root directory - look for gradle.properties * Where to put binaries - .grails/$grailsVersion/lib * We ship "a" grails wrapper still with the project? - yes, called grailsw or grailsw.bat * How do we ship the micronaut libraires? - currently 81mb of the binary, but 40gig * Proposal: keep grails-wrapper in grails-core - purpose of this project is to download a given `grails-wrapper-impl` project jar so that we don't distribute large file sizes (saving money) - forge will use this - sdkman will use grails-wrapper-impl - grails-wrapper will write to .grails directory * Proposal: change grails-wrapper-impl to be able to delegate to one or the other - wrapper will be changed to look for a .grails directory and that directory will contain all of the jar files for shell-cli or forge-cli * Proposed grails structure gradle.properties <- will be required, grails-wrapper will look for this file to determine the grails version instead of the latest .grails <- folder for libs that get downloaded from grailsw invocation. grails-wrapper.jar <- this is the grails-wrapper project's jar file, it will be at the root instead of in .grails grailsw <- this will be the grails-wrapper-impl project grailsw.bat <- bat verison of grailsw ------------------------------------------------------------ Required changes then are: 1. move `grails-wrapper-impl` to grails forge since it will need both forge + grails shell 2. change the name of the shell script for `grails-wrapper-impl` to be `grails` 3. change the name of the shell script for `grails-forge-cli` to `grails-forge-cli` instead of `grails` 4. change the name of the shell script for `grails-shell-cli` to `grails-shell-cli` instead of `grails` 5. enhance `grails-wrapper` in core to download the grails version found in the current project via the gradle.properties (or parent folders until one is found) 6. enhance `grails-wrapper` to save to .grails directory in project root 7. enhance `grails-wrapper-impl` to invoke grails-shell-cli or to invoke grails-forge-cli; add `-t/--type [forge|shell]` as the option. Default to `-t shell` 8. the binaries shipped for sdkman will be `grails-wrapper-impl` - which will include forge & shell 9. ship `grails-shell-cli` and `grails-forge-cli` scripts in addition to `grails` script for sdkman 10. enhance grails-wrapper-impl to have bash completion for --forge, maybe some basics for shell (out of scope for all of shell) Other thoughts: 1. you have to keep forge separate from grails-core because to extend to forge, you have to fork it. 2. for release voting we'll always build both grails-core & grails-forge together. We will vote on them together too. Short term: 1. have compatibility for both grails-shell-cli & grails-forge-cli via the grails-wrapper-impl gradle project in grails-core 2. have the option to use either shell or forge because we ship the original commands & our delegator (grails-wrapper-impl) can call either via a flag Long term: 1. change grails-forge-cli to be grails-wrapper-impl 2. enhance forge to be extendable so that it does not have to be forked like it does today (i.e. similar to the way profiles work) -James