Hi James & James, I never took advantage of the live feature of the grails console, out of curiosity do you know what is/are the main use case/s for it?
On the overall topic, I am not much into it because after the profile feature removal we created a project template we use to build new Dueuno Elements projects. In the end it's easier to maintain and it just requires a package rename and a find all/replace for the project name within files. Michael Yan developed a way to build project templates using Ant scripts, if I remember correctly. To build a custom project template I would personally prefer a script that gives the freedom to do whatever is required (maybe download stuff from a private company repository) instead of a customizable tool which by design is limited. Given all the work required to "unify" the different CLI projects though, I would suggest we release Grails 7 making sure it works with the IntelliJ Grails Plugin but without a rework of the CLI. We may address the topic for Grails 8 with more peace of mind, what do you think? Cheers, Gianluca Sartori -- https://dueuno.com Gianluca Sartori -- https://dueuno.com On Wed, 7 May 2025 at 15:48, James Fredley <jamesfred...@apache.org> wrote: > > James, > > Thank you for walking through this with me yesterday. > > If we look at the collective features and functionality provided across these > tools (grails-shell-cli, grails-wrapper, profiles, grails-forge-cli, > grails-forge-api, start.grails.org, IntelliJ Grails Plugin grails-shell-cli > integration): > > 1. grails project generation, before the the project exists > 2. grails component generation within an existing grails application such as > domains, services, tests, etc. > 3. execution of grails scripts, including from plugins, such as list-plugins > or dbm-update > > I think the following are important to maintain from a feature and > historical/backwards compatibility standpoint. The implementation can and > should be changed, modernized and simplified and most importantly > consolidated, where possible. > > ./grails can start the process which performs all three of the items above > ./grailsw can start the process which performs 2 and 3, within an existing > application > > maintaining an interactive mode on these is a nice to have > > grails-shell-cli and grails-forge-cli have cli autocomplete, with > grails-forge-cli being more advanced. We should maintain this. > > Some of what is provided by these tools overlaps with Gradle features and > tasks or even directly calls Gradle. Where possible and logical, we should > continue to move in that direction while maintaining simple command syntax > and without requiring complex end project changes. > > grails-wrapper and the IntelliJ Grails Plugin both call the grails-shell-cli > when executing grails scripts. So there are at leas 3 ways to get to > grails-shell-cli today. I think keeping these is important, but any > simplification or consolidation of code will make maintenance much easier. > > profiles and grails-forge-core both handle initial grails application > generation and some grails component generation. grails-forge-core is more > advanced and has had substantially more effort applied in recent years. My > opinion is that profiles should exist for Grails 7.0.x, but likely be > deprecated for 7.1.x and then profiles should fold into grails-forge-core for > Grails 8.x.x. As part of this, we need to make it easier to extend > grails-forge like has been done historically with profiles, so companies can > have custom grails-forge features. > > With all that said, I am on board with this proposal of changes. > > James > > On 2025/05/06 16:35:16 James Daugherty wrote: > > 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 > >
