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.

Let's reuse our sample application from the previous blog post:

Continue reading →

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 systemProperties property.

In the following build script we reconfigure all JavaExec tasks in the project. We use the systemProperties method and use the value System.properties. This means any system properties from the command-line are passed on to the JavaExec task.

Continue reading →

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.

Let's run the help task for the wrapper task:

Continue reading →

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 following source file is a simple Spring Boot command-line application. The sample.message property can be configured as by Spring. If there is no value set the default value "default" is used.

Continue reading →

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 @EnableAutoConfiguration or @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.

In the following Gradle build file we add the option --debug to the args property of the bootRun task:

Continue reading →

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.

Let's create a simple class with a constant field DEFAULT, a property message and a message method. We leave out any public keyword:

Continue reading →

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 following build script shows how we add Spring Loaded:

Continue reading →

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.

Suppose we have assigned a String value to a variable in our code. We used the double quoted syntax to do so, like in Java. But we want to change it to a single quoted String value, so to make it explicit the value cannot be a GString implementation. In the following screenshot we see our variable s with a value. We use our shortcut key to open the suggested intentions. We type convert to shorten the list with only conversion options. We see that we can change our String value to dollar slashy, regular expression, multiline or plain String syntax:

Continue reading →

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 group and module of the annotation with the dependency we want to exclude. An alternative syntax is a shorthand version where the group and module are combined into a single String value separated by a colon (:).

In the following Groovy script we have a very simple Spring application with Java (Groovy) based configuration. So we need a dependency on the spring-context module. But we don't want to use the standard Spring logging. Spring used Apache Commons logging and we want to replace it with an SLF4J API implementation: Logback. So we use the @GrabExclude annotation to exclude the commons logging dependency. And we add two extra dependencies to replace it: org.slf4j:jcl-over-slf4j and ch.qos.logback:logback-classic.

Continue reading →

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.

In the following example code we use -Dgroovy.grape.report.downloads=true when we invoke a simple Groovy script with a dependency on Apache Commons library:

Continue reading →

With Grape in Groovy we can add dependency management for our code. Especially the @Grab annotation is very useful to specify dependencies directly in our code. Groovy will download the dependencies if needed and store them in the USER_HOME/.groovy/grapes directory. If we want to change this directory we must set the Java system property grape.root. We specify the new directory to store the downloaded dependencies as a value.

In the following example we have a simple script with a dependency on the Apache Commons library. We use the -Dgrape.root command line option when we run the script and specify the directory deps. After we have run the script we can see the contents of the deps directory to see the downloaded files.

Continue reading →

One of the very nice features of Groovy is that we can implement operator overloading. This blog post is not about how to implement operator overloading, but Groovy's operator overloading also means that operators we know in Java have corresponding methods, which are not available in Java. So instead of using operators in our code we can use the corresponding methods.

The following sample code shows some operators we know in Java and the corresponding methods in Groovy:

Continue reading →