Apache Grails: A Groovy Web Framework Built on Convention

What Apache Grails Solves for Groovy Web Teams

Apache Grails is a framework for building web applications in Apache Groovy, and the README describes the core as "very extensible" with numerous plugins that add features through integration rather than custom code. The problem it addresses is the gap between a general-purpose JVM language and a working web application: routing, controllers, configuration, and add-on integrations such as caching and codecs, which the repository ships as separate modules (grails-controllers, grails-cache, grails-codecs, grails-converters, and others in the top-level layout).

It is aimed at developers who already work on the JVM and want Groovy's syntax rather than Java's, and at teams that prefer generating a project skeleton over assembling libraries by hand. The project notes that releases before 7.0.0 were outside the Apache Software Foundation, which matters if you are reading older tutorials: the governance and release process changed at that boundary. The Apache Software Foundation states it does not offer commercial support for Apache Grails, though the project's support page lists third-party options and explicitly does not endorse them.

The Wrapper, the Two CLIs, and How a Project Gets Built

The mechanism that ties the tooling together is the Apache Grails Wrapper: a 25KB distribution made of a grailsw shell script, a grailsw.bat batch script, and grails-wrapper.jar. It does not contain the framework. It downloads the larger CLIs into $HOME/.grails/wrapper, which is why the README calls it forward compatible: a project created today can pull a newer CLI later without replacing the wrapper.

There are two command-line interfaces behind it. The legacy grails-shell-cli is the one IntelliJ uses to interact with existing applications, and the newer grails-forge-cli is the current generation. The wrapper selects between them with the -t flag, so grailsw -t forge create-app generates an application through Forge while grailsw -t shell help lists the legacy shell's commands. The distinction is not cosmetic: the two CLIs have different command surfaces, and the README points to the snapshot documentation for details rather than documenting both in full.

When you run commands inside an existing project, the wrapper reads the Grails version from gradle.properties and ignores environment variables. That is a deliberate choice with a real consequence: the version your build file pins wins over anything you export in your shell, so a stale gradle.properties silently keeps you on an older line.

Installing Apache Grails and Creating a First Application

The README states that the only requirement is the Java Development Kit. Once a JDK is present, the preferred route is Grails Forge at start.grails.org, with offline CLI applications as the alternative. If you manage several local copies of the CLI, the README recommends SDKMAN!, and this command installs the latest available version:

sdk install grails

Versions installed this way include the grails, grails-shell-cli, and grails-forge-cli commands. The grails command delegates to forge or to the legacy shell.

To create an application with the wrapper instead, extract it, set the version you want, and run the create command. The README gives these steps:

export PREFERRED_GRAILS_VERSION=<version>
grailsw -t forge create-app

Replace the placeholder with the version you intend to use. The wrapper downloads the matching CLI into $HOME/.grails/wrapper and the generator produces a project directory. Inside that directory, the README's start command is:

./gradlew bootRun

That runs the generated application through its Gradle wrapper. What you should see is the application starting under the project's own build, not under a globally installed Grails. If you prefer the source distribution rather than a release download, the README directs you to the INSTALL document in the repository for building and running the CLIs.

Where Apache Grails Stops Being the Right Tool

The framework assumes Groovy and Gradle. The start command is ./gradlew bootRun, and the wrapper resolves its version from gradle.properties, so a team that has standardized on Maven or on a non-JVM runtime is working against the design rather than with it. The related searches show people asking about "grails core maven", and the README offers no Maven path for the tooling; the CLI and wrapper are the documented entry points.

The version situation is the second constraint. The repository shows v8.0.0-RC1 published on 2026-09-23, with 7.2.4 on 2026-09-22 and 7.1.7 on 2026-09-21. Three release lines are receiving activity at once, and the default branch is 8.0.x. An RC is by definition not final, so a team that needs a stable target has to decide deliberately between the 8.0 line and the 7.x lines, and plugin publishers may lag behind whichever one you pick.

A third limitation is support. The README is explicit that the Apache Software Foundation does not offer commercial support for Apache Grails or related applications, and that the third-party options on the support page are listed for information only. If your organization requires a vendor contract with the framework's own maintainers, that contract does not exist here.

Apache Grails and Spring Boot: Different Starting Points

The most common comparison in the search data is Grails versus Spring Boot, and the difference is where the structure comes from. Spring Boot is a Java framework whose core is assembled from starters you choose; Grails is a Groovy framework whose project arrives with a conventional layout, its own CLI, and a plugin registry at plugins.grails.org. Grails applications run through Gradle with bootRun, so the two share the JVM and the build tool, but they do not share the authoring experience.

A concrete difference visible in this repository is the tooling split. Grails ships a wrapper that manages CLI versions, a legacy shell that IntelliJ drives, and a newer Forge CLI, all documented in the README. Spring Boot's tooling story is centered on its own initializer and build plugins. If your team wants dynamic-language controllers and a generator-driven start, Grails is the shorter path. If you want Java throughout, or you are already invested in Spring's starter ecosystem, adding Grails means adding a language and a second set of conventions on top of what you have.

The plugin ecosystem cuts both ways. The README presents plugins as the mechanism for "easy integration of add-on features," and the repository contains modules such as grails-cache, grails-codecs, and grails-data-graphql that show the pattern. But each plugin is a separate release with its own compatibility window, and the README does not document a compatibility matrix for them.

Maintenance, Release Lines, and the Apache-2.0 Licence

The last push to the repository was on 2026-09-23, and the repository is not archived. Releases are frequent: three versions appeared across 2026-09-21 to 2026-09-23. That cadence is good for fixes and expensive for adopters, because it means multiple supported lines at once. The versioning scheme is defined in RELEASE.md under an appendix, so the rules for what constitutes a breaking change live in that file rather than in the README.

Upgrade cost concentrates in two places. First, gradle.properties controls which Grails version the wrapper uses inside a project, so that file is the lever for moving between lines. Second, the plugin ecosystem: the README links to plugins.grails.org but does not state which plugins support which framework version, so verifying each dependency is your work, not something the repository answers.

The licence is Apache License, Version 2.0, stated in the README and carried in the LICENSE file, with SPDX headers in source files. That is a permissive licence with an explicit patent grant and a NOTICE file requirement. It is not legal advice, and if you redistribute Grails or a derivative, your counsel should review the NOTICE and attribution obligations rather than relying on the licence name alone.

Editorial conclusion

Adopt Apache Grails if your team already writes Groovy or JVM code and wants convention-driven web application scaffolding, a plugin ecosystem, and a CLI that can generate a working app from a JDK install. Do not adopt it if you need a non-JVM stack, want a framework with no build-tool coupling, or are unwilling to track a fast release line: v8.0.0-RC1 landed on 2026-09-23 while 7.2.4 and 7.1.7 shipped within days of it. Before committing, confirm which version your project pins in gradle.properties, check whether the plugins you depend on publish for that line, and read INSTALL for the source distribution path if you are building the CLIs yourself.

Frequently asked questions

Official sources

1. apache/grails-core on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases