Since Grails 3 we use Gradle as the build system. This means we also use Gradle to define dependencies we need. The default Gradle build file that is created when we create a new Grails application contains the Gradle dependency management plugin via the Gradle Grails plugin. With the dependency management plugin we can import a Maven Bill Of Materials (BOM) file. And that is exactly what Grails does by importing a BOM with Grails dependencies. A lot of the versions of these dependencies can be overridden via Gradle project properties.
Grails 3.1 allows us to build a runnable WAR file for our application with the
package command. We can run this WAR file with Java using the
-jar option. In Grails 3.0 the
package command also created a JAR file that could be executed as standalone application. Let's see how we can still create the JAR with Grails 3.1.
The Spring Cloud project has several sub projects. One of them is the Spring Cloud Config Server. With the Config Server we have a central place to manage external properties for applications with support for different environments. Configuration files in several formats like YAML or properties are added to a Git repository. The server provides an REST API to get configuration values. But there is also a good integration for client applications written with Spring Boot. And because Grails (3) depends on Spring Boot we can leverage the same integration support. Because of the Spring Boot auto configuration we only have to add a dependency to our build file and add some configuration.
Grails is built on Groovy which is known as a dynamic language. The dynamic nature of Groovy offers a lot of powerful features but also defers the detection of errors from compile time to runtime. To shorten the feedback cycle for your code Groovy has a handy annotation which will make sure that your classes is are statically compiled. This will give you fast feedback for a lot of mistakes and you also will benefit from the increased performance offered by the static complication. Unfortunately in Grails this annotation prevents you from using the very useful dynamic GORM methods like
get() and the dynamic finder methods. Groovy does not recognize these Grails methods during compile time; see the example below.
Since version 2.3 Grails has excellent support for creating REST APIs. This new support comes with some new console commands. Besides the well known
generate-controller command, Grails now comes with a new command which let you generate restful controllers for a given domain class. In the following example, we will create a restful controller using the new
generate-restful-controller command. First we create a domain object
We can include the
version property of domain classes in rendered JSON or XML output. By default the
version property is not included in generated XML and JSON. To enable inclusion of the
version property we can set the configuration property
grails.converters.domain.include.version with the value
true. With this property for both XML and JSON the
version property is included in the output. To only enable this for XML we use the property
grails.converters.xml.domain.include.version and for JSON we use the property
In a Grails application we can organize our controllers into packages, but if we use the same name for multiple controllers, placed in different packages, then Grails cannot resolve the correct controller name. Grails ignores the package name when finding a controller by name. But with namespace support since Grails 2.3 we can have controllers with the same name, but we can use a namespace property to distinguish between the different controllers.
In a previous blog post we learned how we can unit test a template or view independently. But what if we want to unit test a controller that uses the
render() method and a template with the
template key instead of a view? Normally the view and model are stored in the
modelAndView property of the response. We can even use shortcuts in our test code like
model to check the result. But a
render() method invocation with a
template key will simply execute the template (also in test code) and the result is put in the response. With the
text property of the response we can check the result.
Grails adds a couple of methods and properties to our controller classes automatically. One of the methods is the
header() method. With this method we can set a response header with a name and value. The methods accepts two arguments: the first argument is the header name and the second argument is the header value.
I'm using Homebrew "The missing package manager for OS X" for a while now but when it come's to Grails I still install it manually: until now! Installing the most recent version of Grails using Brew is straight forward: