Haha, I had actually written about the possibility to invoke the Forge rest-api in my previous message, but deleted it as I think you can only use the versions currently deployed in one of the 5 "channels": latest, snapshot, next, prev and prev-snapshot.
Using a separate repository for assembling the final Grails distribution could be a good way to decouple the separation of concerns regarding the distribution build process making it easier to handle. Good idea! On 2025/03/03 11:40:46 Michael Yan wrote: > Create a new repository: grails-distribution, writing a Gradle task or > shell script to merge the two (grails-core-7.0.x.zip and > grails-forge-7.0.x.zip) into a one distribution: grails-7.0.x.zip. > So grails-core and grails-forge can be built separately, in the > grails-distribution repo we can also create a new Grails Command eg, > ForgeCommand.groovy to implement the subcommand `forge`. > > That's what I think is the easy way to go, but I think the second option is > the right direction. > Creating a Command in grails-core repo named ForgeCommand.groovy to > implement the subcommand `forge`, but just call the REST API of the backend > grails-forge, this will not have direct build dependencies on each other. > The downside is that it requires a network request just like profiles, but > that's not a problem because downloading dependencies also requires a > network. > The advantage is that there are no direct dependencies on each other, and > the Forge can be developed and bugs fixed quickly. That's how Spring > Initializr has been implemented since the beginning. > > > Mattias Reichel <mat...@apache.org> 于2025年3月3日周一 17:40写道： > > > 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? > > > >> > > > > >> > > > > > > > > > >
