Since Mapstruct version 1.3.0.Final is out, we are able to better integrate with Lombok Builder pattern. Mapstruct is a library that takes away a lot of boilerplate code for mapping between POJO’s. With Mapstruct there is no need for implementing the real mapping itself.
I like to create immutable classes. When using lombok we can easily create immutable classes.
To get an overview of all Gradle tasks in our project we need to run the
tasks task. Since Gradle 5.1 we can use the
--group option followed by a group name. Gradle will then show all tasks belonging to the group and not the other tasks in the project.
We can add Micronaut beans to the application context of a Spring application.
Micronaut has a
MicronautBeanProcessor class that we need to register as Spring bean in the Spring application context.
We can define which Micronaut bean types need to be added to the Spring application context via the constructor of the
This way we can use Micronaut from inside a Spring application.
For example we can use the declarative HTTP client of Micronaut in our Spring applications.
One of the command line options of Gradle is
With this option we run Gradle in offline mode to indicate we are not connected to network resources like the internet.
This could be useful for example if we have defined dependencies in our build script that come from a remote repository, but we cannot access the remote repository, and we still want to run the build.
Gradle will use the locally cached dependencies, without checking the remote repository.
New dependencies, not already cached, cannot be downloaded of course, so in that scenario we still need a network connection.
Gradle added an incubation feature to Gradle 4.6 to add command line options for custom tasks.
This means we can run a task using Gradle and add command line options to pass information to the task.
Without this feature we would have to use project properties passed via the
The good thing about the new feature is that the Gradle
help task displays extra information about the command line options supported by a custom task.
From time to time you only want to run one test, one test method, one class or one package from the command-line. Or on the contrary: you want to exclude / ignore one specific test or group of tests during the build cycle. Excluding tests from the build cycle by the command line usually occurs when the following scenarios meet:
Gradle has incremental build support to speed up our builds.
This means Gradle checks input and output for a task and if something changed the task is executed, otherwise the task is skipped.
In previous posts we learned how to add incremental build support to our tasks with annotations and
outputs property of a task.
When we have a task that has an output file for an input file, like with transformations, we can have a more efficient task using an incremental task action.
With an incremental task action we have extra information on the files that are handled by the task.
We can have different actions based on if an input file is out of date or removed.
This way we can handle only the input files that have changed or removed with incremental builds, instead of all the input files.
Gradle 3.5 introduced the build cache. With the build cache we can reuse task output from builds that can come from different computers.
We can also use the build cache feature for our local builds.
By default the directory to store the cache is located in the Gradle user home directory on our computer (
We can change the directory for the local cache via
settings.gradle of our Gradle project.
For example we could configure a directory in our project file structure to be the build cache directory.
Then it is easy to clean the cache, because it is a directory not shared by other Gradle projects.
With the default directory location in the Gradle user home directory the caches of all Gradle projects we run on our computer are stored in a single directory.
And the cache doesn’t shrink and will only grow we might want to have more control of where the cache of a single Gradle project is stored.
This way we can easily clean the cache, because all files of a project are stored in the directory for that project.
Gradle 3.5 introduced the build cache.
With the build cache we can share task output between builds on different computers.
For example the build output from a continuous integration server can be used on a developer’s computer.
To use the build cache feature we use the command-line option
Instead of using the command-line option
--build-cache we can set the Gradle property
org.gradle.caching with the value
true in the file
gradle.properties of our project.
To set this property for all our projects we set the property in the
gradle.properties file in the Gradle home directory, which is usually at
We can open a Gradle project in IntelliJ IDEA and get support for Gradle inside IntelliJ. Sometimes we need to refresh the project in IntelliJ IDEA, for example when we add a new dependency or plugin in our Gradle build file. We need to refresh the Gradle project so IntelliJ IDEA can work with the changes. The Gradle tool window has an icon to Refresh all Gradle projects. But this means a mouse action and we want to have a shortcut key so we can leave our hands on the keyboard.
Gradle has excellent incremental build support.
This means that Gradle can determine if a task needs to be executed based on the input and output of that task.
If for example nothing changed in one of the input and output files, then the task can be skipped.
We can add incremental build support for our custom tasks by defining the input and output of the task.
We can also define that a task can be skipped when a collection of files or a directory that is the input of the task are empty or not exists.
Gradle offers the
@SkipWhenEmpty annotation we can apply on the input of our task.