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