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.
The auto-configuration feature in Spring Boot adds beans to our application context based on conditions. For example based on the availability of a class on the class path or a environment property beans are enabled or disabled. We must apply the
@SpringBootApplicaiton in our Spring Boot application to make this work. To get an overview of all the configurations that had positive and negative conditional matches in our application we can use the
--debug command-line option. This will print out a report to System.out with a complete overview. We can check why a configuration is applied or not.
There is a catch when we define a constant field in Groovy. Rob Fletcher blogged about this in the post Groovy the public keyword a while ago. When we omit the
public keyword for a method then the method is still accessible as public method, because Groovy makes the method public when the class is compiled. When we leave out the
public keyword for fields Groovy creates a getter and setter method for the field at compile time and turns it into a property that applies to the Java Bean specification. This is also true if the field is static. So if we define a constant value as
static final we must keep in mind that Groovy will generate a getter method so the constant value is a read only property according to Java Bean specification.
When we develop a Spring Boot application we can hot reload newly compiled classes using Gradle. The
bootRun task of the Spring Boot Gradle plugin has support for Spring Loaded. We must add a dependency to Spring Loaded as a dependency for the
classpath configuration in the
buildscript block. If we now use the
bootRun task everything is ready to reload changed classes. Now we can use the continuous build feature of Gradle to listen for changes in our source files to recompile them. The recompiled classes are then reloaded in the running Spring Boot application started with
bootRun. We start a second Gradle instance with the
-t option for the
classes task. This way when we change a source file it gets recompiled automatically and reloaded.
The best IDE to use when developing Groovy code is IntelliJ IDEA. The Groovy plugin has some nice intentions for us that we can use to optimise and refactor our code. We will look at some of the intentions that deal with String values in this blog post. The intentions shown here work in the free Community Edition as well in the paid Ultimate Edition. To see the possible intentions in IDEA we must select the Show Intentions Action. We need to check our shortcut keys to see the assigned shortcut. On my Mac it is for example Alt+Enter. Alternatively we can press the Shift key twice and type in Show intentions. IDEA will show the action with the shortcut key for us.
The built-in dependency mechanism in Groovy is Grape. With Grape we can define dependencies in our code and Groovy will download them and make them available when we run our Groovy application. The easiest way to use it is with the
@Grab annotation with a dependency as the value. If we want to exclude a transitive dependency we use the
@GrabExclude annotation. We must specify the attributes
module of the annotation with the dependency we want to exclude. An alternative syntax is a shorthand version where the
module are combined into a single String value separated by a colon (
Groovy has a advanced feature to define and download dependencies automatically for our code: grape. To get more information about the progress of the dependency resolution and downloading of the dependencies we must use the Java system property
groovy.grape.report.downloads and set it to
true. Groovy uses Ivy under the hood to handle the dependency management. We can get Ivy logging messages by setting the system property
ivy.message.logger.level to a numeric value. The value 4 gives the most logging and value 0 only shows error messages.