Thanks for your input, Michael - this is great info! Larger changes like these should absolutely be considered in the long term.
For now, we have been discussing this merge as a first step for Grails 7.0, allowing projects to be created using both the Shell CLI (for backward compatibility with profiles) and the Forge CLI (for its improved architecture, better feature composition, and compatibility with https://start.grails.org). After project creation, the Shell CLI seems preferable for project-specific tasks due to its user-friendliness. The key question is: how do we best package and distribute a single Grails distribution that enables users to seamlessly invoke both CLIs? Since grails-core and grails-forge reside in separate repositories, they cannot be built and packaged together. Given that grails-core must be built first, the grails-forge CI will need to handle packaging and releasing to SDKMAN. That likely means the proxy/delegate/wrapper command (or script) should also be maintained in grails-forge. Currently, Grails distributions are also published on the GitHub release page in grails-core. Since the distribution won’t be complete without the Forge addition, grails-forge CI could also update the grails-core release page with the final packaged distribution. Just sharing my thoughts to keep the discussion going - open to suggestions on how we can make this work smoothly! On 2025/03/01 00:34:46 Michael Yan wrote: > If you want to merge the two, I suggest that you refer to the gradle > subcommand in the Grails Shell (implemented by GradleCommand.groovy), > you can wrap the Java API of Grails Forge to implement a subcommand forge, > or like spring.groovy script command in the base profile. > > so there are two ways to create a project in Grails Shell: > > grails create-app com.mycompany.blog > grails forge create-app com.mycompany.blog > grails spring init -- // to create spring boot projects > > Michael Yan <rainbo...@gmail.com> 于2025年3月1日周六 08:11写道： > > > I still recommend using only the Grails Shell, and Grails Forge using > > Micronaut and Picocli, although it supports packaging native images, but > > also loses the dynamic nature of Groovy and does not support the ability to > > extend the CLI by the user. > > If we had to provide something like Spring Initializr or Micronaut Launch, > > I would prefer to build it with Spring Boot or Grails, which can take > > advantage of Spring Initializr's existing technologies including front-end > > and back-end APIs, as well as reuse code from the Grails Shell. > > > > James Fredley <jamesfred...@apache.org> 于2025年3月1日周六 03:31写道： > > > >> I look at forge the same way. The blacksmith forged a sword in his > >> forge. > >> > >> grails-forge CLI supports the following 16 commands, only. All but > >> "grails create-functional-test" overlap with grails-shell CLI. > >> > >> create project commands: > >> grails create-app > >> grails create-plugin > >> grails create-restapi > >> grails create-web-plugin > >> grails create-webapp > >> > >> create files: > >> grails create-command > >> grails create-controller > >> grails create-domain-class > >> grails create-functional-test > >> grails create-integration-test > >> grails create-interceptor > >> grails create-scaffold-controller > >> grails create-script > >> grails create-service > >> grails create-taglib > >> grails create-unit-test > >> > >> I like making the commands distinct, for clarity. > >> > >> In interactive mode, both CLIs support auto-completion, with grails-forge > >> CLI autocompletion being more intelligent, but limited by only supporting > >> 16 commands. > >> > >> Both CLIs support features (required & optional) > >> > >> With this proposal, 16 commands with "create-*" are changed to "forge-*" > >> plus "grails forge" would be mapped from the wrapper to run grails-forge > >> CLI. Any others would run grails-shell CLI. > >> > >> This is close enough to having two commands "grails" and "grailsforge", > >> while combining into what appears to be one command, that I am onboard. > >> > >> The hard part will be the plumbing to make this all work. grails-wrapper > >> does this for grails-shell CLI currently, by downloading a fat jar to > >> ".grails/wrapper", but we will need to determine if the grails-forge CLI > >> side is still graalvm native binaries vs standard java. > >> > >> +1 > >> > >> On 2025/02/28 13:40:54 Mattias Reichel wrote: > >> > As many of you know, the old "Grails Shell CLI" (the grails executable > >> > distributed with SDKMAN up to Grails 5, also runnable via ./grailsw) has > >> > been restored in Grails 7. Meanwhile, the "Grails Forge CLI" (introduced > >> > and distributed via SDKMAN for Grails 6, and powering start.grails.org) > >> > remains the current grails CLI in Grails 7.0.0-M1. > >> > > >> > Discussions are ongoing about how best to merge these tools to combine > >> > their strengths. In the last Weekly Meeting (2024-02-27), we considered > >> > generating a single "wrapper" executable that delegates to the > >> appropriate > >> > CLI based on the provided arguments. > >> > > >> > After the meeting, one thought struck me: "forge" is both a noun and a > >> > verb. We could leverage this to differentiate between the two CLIs in a > >> > natural way: > >> > > >> > - grails vs. grails forge for interactive mode > >> > - grails create-app myApp vs. grails forge-app myApp > >> > - grails create-plugin myPlugin vs. grails forge-plugin myPlugin > >> > - grails create-controller myController vs. grails forge-controller > >> > myController > >> > ...and so on. > >> > > >> > Since "forging" is pretty much all that the "Grails Forge CLI" does, > >> this > >> > could make the distinction intuitive for users. > >> > > >> > Of course, there may be caveats that I have not thought of, but I > >> wanted to > >> > put this idea out there for brainstorming. Thoughts? > >> > > >> > > >
