Gradle

Gradle Goodness: Use bill of materials (BOM) As Dependency Constraints

Posted on by  
Hubert Klein Ikkink

Since Gradle 5 we can easily use a bill of materials (BOM) in our build file to get recommended dependency versions. The dependency versions defined in the BOM are dependency constraints in Gradle. This means the dependencies we define in our build that are part of the BOM don’t need a version, because the version is resolved via the dependency constraint that is defined in the BOM. Also transitive dependency versions are resolved using the BOM if applicable. We use the dependency handler method platform to define the BOM we want to import. The versions in the BOM are recommendations. We can override the recommendation by specifying the version for a dependency found in the BOM with an explicit version.

Continue reading →

Gradle Goodness: Manage Dependency Versions With Dependency Constraints

Posted on by  
Hubert Klein Ikkink

From Maven builds we know the dependencyManagement section in our POM file. In the section we can describe dependencies with their version and later in the dependencies section we can refer to the dependency without the version. We can use dependency constraints in Gradle to do the same thing. A dependency constraint can be used to define the version or version range for a dependency defined in our scripts or a transitive dependency. Just like a dependency the dependency constraint is defined for a configuration, so we can fine tune the constraints to the correct configuration.

Continue reading →

Using QueryDSL annotation processor with Gradle and IntelliJ IDEA

Posted on by  
Tom de Vroomen

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:

Continue reading →

Grails Goodness: Changing Gradle Version

Posted on by  
Hubert Klein Ikkink

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.

Continue reading →

Gradle Goodness: Getting Information About Buildscript Dependencies

Posted on by  
Hubert Klein Ikkink

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

Continue reading →

Groovy Goodness: Customise Groovydoc Output With Gradle

Posted on by  
Hubert Klein Ikkink

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:

Continue reading →

Ratpacked: Running With LiveReload Using Gradle

Posted on by  
Hubert Klein Ikkink

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.

Continue reading →

Gradle Goodness: Apply External Script With Plugin Configured Through Buildscript

Posted on by  
Hubert Klein Ikkink

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.

Continue reading →

Gradle Goodness: Download Javadoc Files For Dependencies In IDE

Posted on by  
Hubert Klein Ikkink

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.

Continue reading →

Gradle Goodness: Pass Java System Properties To Java Tasks

Posted on by  
Hubert Klein Ikkink

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.

Continue reading →

shadow-left