FYI: Here are the PRs for this change: https://github.com/apache/grails-core/pull/14735 https://github.com/apache/grails-forge/pull/575
See the PR descriptions for how it all works and how to test. On Sat, May 10, 2025 at 3:03 AM Gianluca Sartori <g.sart...@gmail.com> wrote: > Okay I understand. My proposal was to not broaden the scope for Grails > 7. From my point of view the most important thing is to make it work > with the intelliJ IDEA plugin. That to me has a higher impact from a > communication side than a technical one. > > We are still fighting the "Grails is dead" thing... > > Gianluca Sartori > -- > https://dueuno.com > > On Fri, 9 May 2025 at 16:09, James Daugherty > <jdaughe...@jdresources.net.invalid> wrote: > > > > Unfortunately since we still ship shell, we have to do something here. > My > > proposal is how we can move forward with integrating both and long term > > look at removing shell again. > > > > > > Mattias & James F both have also run across caching issues that can lead > to > > failures too. I would like to propose we stop installing to the user > home > > and create a .grails under the project directory. This would prevent > > failures when working across multiple versions. It would also make this > > way easier to test and mimic gradle’s behavior. > > > > > > > > On Wed, May 7, 2025 at 3:07 PM Gianluca Sartori <g.sart...@gmail.com> > wrote: > > > > > 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 > > > > > > > > >
