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