You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@grails.apache.org by Michael Yan <ra...@gmail.com> on 2025/03/01 00:11:40 UTC
Re: CLI Merge in Grails 7
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 <ja...@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?
> >
>
Call for Grails presentations for Apache Community Over Code North America
Posted by James Fredley <ja...@apache.org>.
There is a Groovy track this year and we are hoping to have some Grails presentations. I plan to submit one myself.
Conference site: https://communityovercode.org/
Submit proposals by 23:59 UTC on April 21, 2025. https://buff.ly/IYCIVuq
The call for presentations for Community Over Code NA is now open! We are accepting presentation proposals for any topic related to the ASF mission of producing free software for the public good. This includes, but is not limited to:
✅ AI Plumbers
✅ Data (compute, engineering, and storage)
✅ Cassandra
✅ Community
✅ Developer experience
✅ Fintech: Building Secure Solutions
✅ Geospatial
✅ Groovy
✅ Incubator
✅ Industrial Internet of Things
✅ Infrastructure
✅ OpenLakehouse
✅ Performance engineering
✅ Search
✅ Security
✅ Streaming
✅ Web servers/Tomcat
Re: CLI Merge in Grails 7
Posted by Michael Yan <ra...@apache.org>.
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 <ma...@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 <ra...@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 <ja...@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?
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: CLI Merge in Grails 7
Posted by Mattias Reichel <ma...@apache.org>.
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 <ma...@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 <ra...@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 <ja...@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?
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: CLI Merge in Grails 7
Posted by Michael Yan <ra...@gmail.com>.
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 <ma...@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 <ra...@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 <ja...@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?
> > >> >
> > >>
> > >
> >
>
Re: CLI Merge in Grails 7
Posted by Mattias Reichel <ma...@apache.org>.
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 <ra...@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 <ja...@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?
> >> >
> >>
> >
>
Re: CLI Merge in Grails 7
Posted by Michael Yan <ra...@gmail.com>.
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 <ra...@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 <ja...@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?
>> >
>>
>