If we create our own tasks in Gradle we usually extend from the DefaultTask or a subclass of DefaultTask. The tasks that are included with Gradle also extend from this class. Gradle will create a proxy class for the actual class implementation and adds (among other things) also a property setter method. The method has the name of the property and has a single argument of the same type as the property. It is different from the setProperty and getProperty methods already added by Groovy. For example if we have a task with a property with the name message of type String then Gradle will add the method message(String) to the proxy class.
In the following example task we have one property user:
Continue reading →
When we define dependencies in Gradle we usually define them to compile source files. For example we create a Java project and need the Spring framework, then we define a dependencies configuration block with a dependency to the Spring libraries for the compile configuration. We can also use the dependencies configuration block to define dependencies on artifacts used in other tasks than the compiling source files. For example we might have a multi-module project where we want to aggregate artifacts from several projects into one place with the Copy task.
In the following example we have a multi-module project where projects projectA and projectB have a dist task to create a Tar file. In the project docker we want to copy the Tar files from those projects into the build directory. To achieve this we first apply the Gradle base plugin, because then we can use the artifacts configuration block. Inside the artifacts configuration we define that our dist task that creates the Tar file is assigned to the dockerDist configuration as artifact. This sets up our projects that create the artifact. The docker project uses these artifacts in the task prepare. The prepare task copies the artifacts of projectA and projectB to the build directory of the docker project.
Continue reading →
With Groovy we can configure the compiler for our source files just like we can configure the Groovy compilation unit when we use GroovyShell to execute scripts. We can for example add annotations to source files, before they are compiled, without adding them to the actual source code ourselves. Suppose we want to apply the TypeChecked or CompileStatic AST transformation annotation to all source files in our project. We only have to write a configuration file and specify the name of the configuration file with the --configscript option of the Groovy compiler. If we use Gradle to build our Groovy project we can also customise the GroovyCompile task to set the configuration file.
The configuration file has an implicit object with the name configuration of type CompilerConfiguration. Also there is a builder syntax available via the CompilerCustomizationBuilder class. Let's look at both ways to define our custom configuration. We want to add the CompileStatic annotation to all classes, together with the ToString AST transformation annotation. Next we also want to add the package java.time as implicit import for our source files. This means we don't have to write an import statement in our code to include classes from this package. Finally we add a ExpressionChecker that will fail the compilation of our project if a variable name is only 1 character. We assume we use Gradle to build our project and we place the file groovycConfig.groovy in the directory src/groovyCompile. We must not name the file configuration.groovy, because there is already a variable with the name configuration in the script and this will confuse the compiler.
Continue reading →
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:
Continue reading →
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:
Continue reading →
Interesting links for week 8 2016:
Continue reading →
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
Continue reading →
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.
Continue reading →
A Gradle build script is actually a Groovy script. The Gradle API uses Groovy a lot so we can have a nice DSL to define our builds. But we can also use Java code in a Groovy script. The compiler that compiles the build script understands Java code as well as the Groovy code. Sometimes I hear from people new to Gradle that they have difficulty understanding the DSL. I thought it would be a fun exercise to write a very simple Gradle build script using Java syntax.
Most notable is that we invoke the getProject method to get a reference to org.grade.api.Project. In the Gradle DSL we could use the simpler Groovy property reference project or just leave it out, because all method invocations in the build script are delegated to Project.
Continue reading →
In a previous post we learned how to use the NamedDomainObjectContainer class. We could create new objects using a nice DSL in Gradle. But what if we want to use DSL syntax to create objects within objects? We can use the same mechanism to achieve this by nesting NamedDomainObjectContainer objects.
We want to support the following DSL to create a collection of Server objects, where each server can have multiple Node objects:
Continue reading →
