Gradle has the built-in task wrapper to create a Gradle wrapper. The Gradle wrapper can be part of our project so other people can build our project with Gradle, without the need for them to install Gradle. Also if we specify the Gradle wrapper we can make sure the correct Gradle version is used. To specify the version we must use the option --gradle-version. This version can be different than the Gradle version we use to create the Gradle wrapper. Since Gradle 3.1 we can also specify the distribution type of the Gradle wrapper. We choose between a binary distribution or the all distribution, which contains documentation and source code. Especially IDEs like to have the all distribution type, so they can provide better help in their editors. With the following wrapper command we create a wrapper for Gradle 3.1 and the all distribution type. For a binary distribution we either use the value bin or we don't specify the option, so Gradle falls back to the default value bin.

$ gradle wrapper --gradle-version 3.1 --distribution-type all
:wrapper

BUILD SUCCESSFUL

Total time: 1.012 secs

$

Continue reading →

With the Gradle Wrapper task we can specify the name of the generated script files. By default the names are gradlew and gradlew.bat. The Wrapper task has the property scriptFile. We can set a different value for this property to let Gradle generate the script files with a different name.

In the following example we use the value mvnw (they will be surprised the build is so fast... ;-)) as the value:

Continue reading →

Sometime we need to define a project property in our Gradle build file for which the value must be evaluated later than the assignment. We can do this in different ways in Gradle. For example for a String type property we can rely on Groovy's support for lazy String evaluation. If the property is of a different type we can use Closure to define the value. The Closure code is not executed during the configuration phase directly, but we can write code to invoke the Closure at the right moment and get the value. Finally we can use the afterEvaluate method of the Project class to define a lazy property. Let's look at the different options we have with some code samples.

First we look at a lazy String property. We illustrate this with an example of a multi-project build with the following layout:

Continue reading →

Sometimes we want to include the classes from a plugin, like tasks, in our build class path without actually applying the plugin. Or we want to add the classes to the root project and actually apply the plugin in subprojects. We can achieve this with a buildScript block and add the plugin dependency to the classpath configuration. But we can also do this with the newer plugins configuration block. Inside the plugins block we define the id and the version of the plugin, and since Gradle 3.0 we can also use the apply method. We have to set the value false to include the plugin to the class path, but not apply it to the project.

In the following example we add the Asciidoctor plugin to our build file, but we only want to use the AsciidoctorTask task from this plugin.

Continue reading →

Since Gradle 3 the Gradle daemon is automatically used to run Gradle. This means Gradle will startup up faster after a first run. Gradle tries to re-use a daemon if it is available. We can check the status of the Gradle daemon processes with the new command-line option --status. We get the status results for the Gradle daemons with the same Gradle version that is used to view the status. So when we use Gradle 3.0 with the --status option we only see the 3.0 Gradle daemons.

The following example shows the sample output of running gradle with the --status option:

Continue reading →

With a Spring (Boot/Cloud) application you can create a fully executable JAR, where the jar can be run from the command-line by just calling ./my-own-jar-0.0.1.jar. My colleague Mr. Haki wrote Grails Goodness: Creating A Fully Executable Jar. Together with the famous one-liner of Josh Long in mind: "Make JAR not WAR!", create a JAR whenever you develop a Spring Boot/Cloud application. As described in Mr. Haki's blog, it is very easy to make our Spring application executable:

 org.springframework.boot
    spring-boot-maven-plugin
    true 

## Gradle configuration

```gradle
apply plugin: 'spring-boot'

springBoot {
    executable = true
}

Continue reading →

I love code. I take care of my code and I like my code to be formatted nicely. No matter if I'm on Eclipse, Netbeans or IntelliJ, I want my code to be formatted the same. Nowadays we have EditorConfig. In the source code we can place a file .editorconfig with formatting instructions. These instructions can be read by many Tools like Eclipse, Netbeans, IntelliJ and VisualStudio. If we create an .editorconfig file with formatting instructions, these rules are automatically applied.

An example of an .editorconfig file looks like:

Continue reading →

If we have a Gradle task of type Test we can use a filter on the command line when we invoke the task. We define a filter using the --tests option. If for example we want to run all tests from a single package we must define the package name as value for the --tests option. It is good to define the filter between quotes, so it is interpreted as is, without any shell interference.

If we configure the test task to output the test class name we can see that which tests are executed. In the following snippet we reconfigure the test task:

Continue reading →

Gradle 2.13 added a new method to get a property value: findProperty. This method will return a property value if the property exists or null if the property cannot be found. Gradle also has the property method to return a property value, but this method will throw an exception if the property is missing. With the new findProperty method and the Groovy elvis operator (?:) we can try to get a property value and if not found return a default value.

In the following example we have a task that tries to print the value of the properties sampleOld and sampleNew. We use the findProperty for sampleNew and the property method for sampleOld:

Continue reading →

IntelliJ IDEA 2016.1 introduced better support for Gradle source sets. Each source set in our project becomes a module in the IntelliJ IDEA project. And each module has it's own dependencies, also between source sets. For example if we simply apply the java plugin in our project we already get two source sets: main and test. For compiling the test sources there is a dependency to the main source set. IntelliJ now knows how to handle this.

Let's create a sample Gradle build file with an extra custom source set and see what we get in IntelliJ IDEA. In the following example build file we add the source set api. This source set contains interfaces without implementations. The implementations for the interfaces are in the default main source set. Finally we have some tests in the test source set that depend on the classes generated by the api and main source sets.

Continue reading →

To create IntelliJ IDEA project files with Gradle we first need to apply the idea plugin. We can then further customise the created files. In this blog post we will add a Spring facet to the generated module file. By adding the Spring facet IntelliJ IDEA can automatically search for Spring configuration files. We can then use the Spring view to see which beans are configured in our project.

In the following example build file we use the withXml hook. This method is invoked just before the XML file is generated. We get an argument of type XmlProvider. From the XmlProvider we can access the XML as org.w3c.dom.Element, StringBuilder or groovy.util.Node. We use Node to alter the XML. We check if a FacetManager component is available. We need this to add a facet of type Spring.

Continue reading →

When we use the IDEA plugin in Gradle we can generate IntelliJ IDEA project files. We can customise the generated files in different ways. One of them is using a simple DSL to configure certain parts of the project file. With the DSL it is easy to set the version control system (VCS) used in our project.

In the next example build file we customise the generated IDEA project file and set Git as the version control system. The property is still incubating, but we can use it to have a proper configuration.

Continue reading →