I don't see why Grails Forge doesn't support specifying Grails version when creating new project, which also saves server resources for deployment. This is something that Grails has supported since the introduction of Profiles in 3.0, I have fully implemented in Grace 2023.0.0, and in 2023.1 it is also possible to support specific versions of Spring Boot.
On 2025/03/03 12:14:21 Mattias Reichel wrote: > 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? > > > > >> > > > > > >> > > > > > > > > > > > > > > >
