Great projects keep moving forward. JUnit5 is available since September 2017 and Spock 1.2 is already complete. Since Spock is based on JUnit4, I wondered what it would take to use Spock 1.2 together with JUnit5.
As it turns out, it’s quite easy to make that happen. JUnit5 comes with the vintage engine to run JUnit4 based tests. If that is available on the test classpath, your Spock tests run like on JUnit4.
Making IntelliJ understand your QueryDSL generated classes needs some work. QueryDSL has an annotation processor to generate Q-classes from your entities. Just running the annotation processor doesn’t mean your IDE will understand where to find the generated classes. I was struggling to get IntelliJ IDEA picking up the generated classes. Probably there are more ways to get this done in Gradle, but I found out one that’s pretty easy to configure, without any adjustments to you IntelliJ settings. Because you could configure the annotation processor via the IntelliJ settings in the Annotation Processor screen (Build, Execution, Deployment → Compiler → Annotation Processors). It would be easier if you can achieve the same just using Gradle. With the following in your Gradle build file, it generates the classes and instructs IntelliJ where to find the classes:
If you’re using Lombok in your entities, generating the QueryDSL classes will fail, as it won’t understand the Lombok annotations. To solve this you have to add the Lombok dependency to the annotationProcessor block.
Since Grails 3 Gradle is used as the build tool. The Grails shell and commands use Gradle to execute tasks. When we create a new Grails 3 application a Gradle wrapper is added to our project. The Gradle wrapper is used to download and use a specific Gradle version for a project. This version is also used by the Grails shell and commands. The default version (for Grails 3.0.12) is Gradle 2.3, which is also part of the Grails distribution. At the time of writing this blog post the latest Gradle version is 2.10. Sometimes we use Gradle plugins in our project that need a higher Gradle version, or we just want to use the latest version because of improvements in Gradle. We can change the Gradle version that needs to be used by Grails in different ways.
Grails will first look for an environment variable GRAILS_GRADLE_HOME. It must be set to the location of a Gradle installation. If it is present is used as the Gradle version by Grails. In the following example we use this environment variable to force Grails to use Gradle 2.10:
If our build script needs extra dependencies, for example when we add a plugin, then we use a buildscript configuration block and define our dependencies in there. These dependencies are added to a configuration with the name classpath. To see the dependencies and transitive dependencies for the classpath configuration we use the task buildEnvironment. This task is available since Gradle 2.10
Suppose we have the following build file where define the Asciidoctor plugin using the new plugins configuration block. We also add a dependency for PDF generation in the buildscript block:
When we write our Groovy application we of course add documentation to our classes. If we use Gradle to build our project we can run the groovydoc task that is added by the Groovy plugin to generate documentation. We can set document and windows titles and a footer for the generated documentation by changing some properties of the groovydoc task. If we want some further customisation we must take some extra steps. The groovydoc task uses the GroovyDoc tool that is bundled with the Groovy library. GroovyDoc tool uses the GStringTemplateEngine to generate the documentation. The default template files are stored in the package org.codehaus.tools.groovydoc.gstringTemplates. The following files are in the package:
└── org
└── codehaus
└── groovy
└── tools
└── groovydoc
└── gstringTemplates
├── classLevel
│ └── classDocName.html
├── packageLevel
│ ├── package-frame.html
│ └── package-summary.html
└── topLevel
├── allclasses-frame.html
├── deprecated-list.html
├── help-doc.html
├── index-all.html
├── index.html
├── overview-frame.html
├── overview-summary.html
└── stylesheet.css
When we develop our Ratpack application using Gradle we can use the continuous build feature of Gradle. If we make a change in a source file then our Ratpack application is automatically restarted. It would be nice to combine this with LiveReload using the Gradle LiveReload plugin. Then when we change for example a stylesheet file it is automatically reloaded in the web browser without invoking a refresh action.
In the following build file we add the Gradle LiveReload plugin and configure it to watch for changes in the output directory of the processResources task. This task is executed when we change a file in the source directory if we use Gradle's continuous build feature.
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.
Let's create a simple Gradle build that we want to include in our main Gradle 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 USER_HOME/.gradle directory.
In the following example gradle.properties file we assign values to some properties that can be used in all Gradle builds we run on our computer. We store the file in USER_HOME/.gradle.
Gradle has an idea and 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.
In the example build file we use the idea and eclipse plugins. We also add an idea and eclipse configuration block. The place where we need to set the property downloadJavadoc is a bit different, but the end result will be the same.
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.
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:
When we execute a Gradle test task in IntelliJ IDEA the IDE test runner is used. This means we can get a nice overview of all tests that have run. If a test is successful we get a green light, otherwise it is red in case of an error or orange in case of a failure. Gradle also generates a nice HTML report when we run the test task. It is placed in the directory build/reports/tests/. IntelliJ IDEA has a button which opens this report when we click on it. The following screenshot shows the button with the tooltip that opens a Gradle test report:
