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 →
Interesting links for week 40 2016:
Continue reading →
Suppose we have a custom task with some properties that can be configured.
Normally we would add the configuration in the build script.
But we can also use command line options to configure a task.
So when we run the task from the command line we can provide a configuration value for the task on the command line.
To see which command line options are available for a task we can use the Gradle built-in task help followed by the option --task and the task name.
To indicate a property as command line option we use a @Option annotation.
We can specify the name of the command line option, a short description and also the order that is used to display the options with the help task.
Let's create a sample custom task and use the @Option annotation.
In the following build file we create a custom task GenerateVersionFile.
This task generates a file with a default name of version.txt in the build/ directory.
The file contains the project version value. We make the property that defines the output filename as a command line option.
This way the name can be defined when we run Gradle (and still of course using the default configuration in a build file).
Continue reading →
In a previous post we learned that we can check a specific exception is not thrown in our specification with the notThrown method.
If we are not interested in a specific exception, but just want to check no exception at all is thrown, we must use the noExceptionThrown method.
This method return true if the called code doesn't throw an exception.
In the following example we invoke a method (cook) that can throw an exception.
We want to test the case when no exception is thrown:
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 →
The Software Development Kit Manager (SDKMAN!) is an awesome and very useful tool.
We can use it to install and manage candidates like Groovy, Grails, Griffon and Gradle.
If we want to know if a new version of an installed candidate is available we use the outdated command.
SKDMAN! returns a list of candidates with newer versions and also displays the version we have and is available.
If we specify the candidate we can see if for that specific candidate a newer version is available.
For example we can get the following results:
Continue reading →
Suppose we want to support partial JSON responses in our Ratpack application.
The user must send a request parameter with a list of fields that need to be part of the response.
In our code we must use the value of the request parameter and output only the given properties of an object.
We implement this logic using a custom renderer in Ratpack.
Inside the renderer we can get access to the request parameters of the original request.
In our example Ratpack application we have a Course class, which is a simple class withs some properties:
Continue reading →
We can use the environment variable SPRING_APPLICATION_JSON with a JSON value as configuration source for our Grails 3 application.
The JSON value is parsed and merged with the configuration.
Instead of the environment variable we can also use the Java system property spring.application.json.
Let's create a simple controller that reads the configuration property app.message:
Continue reading →
Ratpack has a lot of options to add configuration data to our application.
We can use for example YAML and JSON files, properties, environment variables and Java system properties.
Groovy has the ConfigSlurper class to parse Groovy script with configuration data.
It even supports an environments block to set configuration value for a specific environment.
If we want to support Groovy scripts as configuration definition we write a class that implements the ratpack.config.ConfigSource interface.
We create a new class ConfigSlurperConfigSource and implement the ConfigSource interface.
We must implement the loadConfigData method in which we read the Groovy configuration and transform it to a ObjectNode so Ratpack can use it:
Continue reading →
We have many ways to provide configuration properties to a Spring (Boot) application.
We can add our own custom configuration properties format.
For example we can use Groovy's ConfigObject object to set configuration properties.
We need to read a configuration file using ConfigSlurper and make it available as a property source for Spring.
We need to implement two classes and add configuration file to support a Groovy configuration file in a Spring application.
First we need to write a class that extends the PropertySource in the package org.springframework.core.env.
This class has methods to get property values based on a given key.
There are already some subclasses for specific property sources.
There is for example also a MapPropertySource class.
We will extend that class for our implementation, because we can pass our flattened ConfigObject and rely on all existing functionality of the MapPropertySource class:
Continue reading →
To define configuration sources for our Ratpack application we have several options.
We can set default properties, look at environment variables or Java system properties, load JSON or YAML formatted configuration files or implement our own configuration source.
When something goes wrong using one of these methods we want to be able to handle that situation.
For example if an optional configuration file is not found, we want to inform the user, but the application must still start.
The default exception handling will throw the exception and the application is stopped.
We want to customise this so we have more flexibility on how to handle exceptions.
We provide the configuration source in the serverConfig configuration block of our Ratpack application.
We must add the onError method and provide an error handler implementation before we load any configuration source.
This error handler will be passed to each configuration source and is execute when an exception occurs when the configuration source is invoked.
The error handler implements the Action interface with the type Throwable.
In our implementation we can for example check for the type of Throwable and show a correct status message to the user.
Continue reading →
