To quickly start with a Spring project we can use the website start.spring.io. Via a user interface we can set project properties and at the end we have a project archive (Zip or gzipped Tar file) or build file (pom.xml or
build.gradle). We can also directory access an URL to create the output files and we set the properties via request parameters. This way you can share a link with someone and if they click on it they will download the generated project archive or build files.
When we create our own custom tasks we might need to support lazy evaluation of task properties. A Gradle build has three phases: initialisation, configuration and execution. Task properties can be set during the configuration phase, for example when a task is configured in a build file. But our task can also evaluate the value for a task property at execution time. To support evaluation during execution time we must write a lazy getter method for the property. Also we must define the task property with
def or type
Object. Because of the
Object type we can use different types to set a value. For example a Groovy
Callable interface implementation can be used to execute later than during the configuration phase of our Gradle build. Inside the getter method we invoke the
Callable to get the real value of the task property.
Suppose we use the Gradle
apply from: statement to import another Gradle build file into our build file. The external build file uses a Gradle plugin that needs a
buildscript block to define the
classpath configuration with the classes needed for the plugin. We cannot use the plugin id inside our external build script to use it, but we must use the type of the plugin. Otherwise Gradle cannot resolve the plugin from the main build file.
To define project properties outside the Gradle build file, we can define them in a file
gradle.properties in our project directory. If we want to define property values that are used by all Gradle builds we can create a file
gradle.properties in the
GRADLE_USER_HOME directory. By default this is in the
Gradle has an
eclipse plugin that we can use to configure IntelliJ IDEA and Eclipse project files. When we apply these plugins to our project we get extra tasks to generate and change project files. Inside our Gradle build file we get new configuration blocks to specify properties or invoke methods that will change the configuration files. One of the nice things to add is to let the IDE download Javadoc files for dependencies in our Java/Groovy projects. By default the sources for a dependency are already downloaded and added to the project, but Javadoc files are not downloaded.
To start Grails in interactive mode we simply type
grails on the command line. This starts Grails and we get an environment to run Grails commands like
run-app. Since Grails 3 the underlying build system has changed from Gant to Gradle. We can invoke Gradle tasks in interactive mode with the
gradle command. Just like we would use Gradle from the command line we can run the same tasks, but this time when Grails is in interactive mode. Grails will use the Gradle version that belongs to the current Grails version.
We even get TAB completion for Gradle tasks.
In a previous post we learned that configuration property values can be passed via environment variables. With Spring Boot we can also pass the values using Java system properties. So if we have a property
sample.message then we can use
-Dsample.message=value to pass a value when we run the application. If we use the Spring Boot Gradle plugin we must reconfigure the
bootRun task to pass Java system properties from the command-line.
Gradle is of course a great build tool for Java related projects. If we have tasks in our projects that need to execute a Java application we can use the
JavaExec task. When we need to pass Java system properties to the Java application we can set the
systemProperties property of the
JavaExec task. We can assign a value to the
systemProperties property or use the method
systemProperties that will add the properties to the existing properties already assigned. Now if we want to define the system properties from the command-line when we run Gradle we must pass along the properties to the task. Therefore we must reconfigure a
JavaExec task and assign
System.properties to the
To see which tasks are available for a Gradle project we can invoke the
tasks task. With this task all tasks are printed to the console with their description. To get more information about a specific task we can use the Gradle
help task with the command-line option
--task followed by the task name. Gradle prints out the path, type, description, group and optional options for the task.
Spring Boot has many options for externalising the configuration of our application. One of the options it to use OS environment variables. We need to follow certain rules to name the environment variable and then Spring Boot will use the value of variable to set a configuration property. The property name must be in uppercase and any dots need to be replaced with underscores. For example the configuration property
sample.message is set with the environment variable
SAMPLE_MESSAGE. This feature can be useful in a continuous integration environment where we can set environment variables or just when developing locally. The nice thing is that this also works when we use the Spring Boot Gradle plugin. The environment variables are passed on to the Java process that the
bootRun task starts.