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 > > > > > >
