My name is Hubert A. Klein Ikkink also known as mrhaki. I work at the great IT company JDriven. Here I work on projects with Java, Groovy, Gradle, Asciidoctor and more. At JDriven we focus on enterprise technologies. All colleagues support craftsmanship and are very eager to learn new technologies. This is truly a great environment to work in.
With Asciidoctor we can create numbered lists easily. When we want to change the number the list starts with we use the start attribute when we define the list.
== Numbered List
.Default
. Makes writing easy
.. Keep focus
.. Syntax
. Different output formats
// Start this list from 10.
[start=10]
.Start from 10
. Makes writing easy
// We can use it on all levels.
[start=10]
.. Keep focus
.. Syntax
. Different output formats
Document attributes are like variables for your Asciidoctor document. Normally when we reference an attribute that is not set in our Asciidoctor markup the reference is still in the output. This is very handy, because we immediately see that a document attribute is not set. But we can customize this behavior with the document attribute attribute-missing. We can use the default value skip, which leaves the reference in the output. Another option is drop, which means the reference is dropped from the output. Finally we can set the value to drop-line, where the complete line with the attribute reference is dropped from the output.
In the following sample Asciidoctor markup we set the three values for the attribute attribute-missing:
Recently I had to access the XML-RPC WordPress API for a small project. Luckily with Groovy we can access a XML-RPC server in a Groovy way. We need to use the Groovy XML-RPC module, which is a separate dependency. The module provides code to write a XML-RPC server, but also code to access a XML-RPC server as client. We use the class XMLRPCServerProxy in the package groovy.net.xmlrpc to act as a client to a XML-RPC API. The XMLRPCServerProxy class only needs to know the URL to access the API. All API methods are dynamically dispatched to the server, so it is very flexible.
In the following Groovy script we use the WordPress XML-RPC API to access posts:
Spock supports JUnit rules out of the box. We simply add a rule with the @Rule annotation to our Spock specification and the rule can be used just like in a JUnit test. The Spring Boot project contains a JUnit rule OutputCapture to capture the output of System.out and System.err.
In the following example specification we apply the OutputCapture rule and use it in two feature methods:
Since Groovy 2.4 we can use the indices property on a Collection to get the indices of the elements in the collection. We get an IntRange object as a result.
def list = [3, 20, 10, 2, 1]
assert list.indices == 0..4
// Combine letters in alphabet
// with position (zero-based).
def alphabet = 'a'..'z'
def alphabetIndices = [alphabet, alphabet.indices].transpose()
// alphabetIndices = [['a', 0], ['b', 1], ...]
// Find position of each letter
// from 'groovy' in alphabet.
def positionInAlphabet = 'groovy'.inject([]) { result, value ->
result << alphabetIndices.find { it[0] == value }[1] + 1
result
}
assert positionInAlphabet == [7, 18, 15, 15, 22, 25]
Groovy adds the pop and push methods to the List class. With the pop method we remove the last element of the list. And with the push method we add an element to the end of the list.
def list = ['Groovy', 'is', 'great!']
// Remove last item from list
// with pop().
assert list.pop() == 'great!'
assert list == ['Groovy', 'is']
// Remove last item
// which is now 'is'.
list.pop()
// Add new item to end of
// the list (equivalent for add()).
list.push('rocks!')
assert list == ['Groovy', 'rocks!']
In Groovy we can use the head and tail methods for a long time on Collection objects. With head we get the first element and with tail the remaining elements of a collection. Since Groovy 2.4 we have a new method init which returns all elements but the last in a collection.
In the following example we have a simple list and apply the different methods:
We know Groovy has a lot of nice methods for working with collections. For example in previous blog posts we have seen how to take or drop elements from a list and even with a condition. Since Groovy 2.4 we can now also use the dropRight and takeRight methods to take or drop elements from the end of the list.
In the following example we have a simple list and we use the dropRight and takeRight methods to get elements from the list:
Migrating from Ant to Gradle is very easy with the importBuild method from AntBuilder. We only have to add this single line and reference our existing Ant build XML file and all Ant tasks can now be executed as Gradle tasks. We can automatically rename the Ant tasks if we want to avoid task name collisions with Gradle task names. We use a closure argument with the importBuild method and return the new task names. The existing Ant task name is the first argument of the closure.
Let's first create a simple Ant build.xml file:
In our Asciidoc markup we can include delimited blocks, like sidebars, examples, listings and admonitions. A delimited block is indicated by a balanced pair of delimiter characters. For example a sidebar starts and ends with four asterisk characters (****). If we want to nest another delimited block of the same type we must add an extra delimiter character at the start and end of the nested block. So when we want to nest another sidebar block inside an existing sidebar block we must use five asterisk characters (*****).
In the following example Asciidoc source we have several blocks with nested blocks:
If we run a Gradle build and one of the tasks fails, the whole build stops immediately. So we have fast feedback of our build status. If we don't want to this and want Gradle to execute all tasks, even though some might have failed, we use the command line option --continue. When we use the --continue command line option Gradle will execute every task where the dependent tasks are not failing. This is also useful in a multi-module project where we might want to build all projects even though some may have failing tests, so we get a complete overview of failed tests for all modules.
In the following Gradle build file we have two tasks. The task failTask throws a TaskExecutionException to purposely fail the task. The successTask will not fail:
If we use Gradle in a multi-module project we can define project dependencies between modules. Gradle uses the information from the project dependencies to determine which tasks need to be run. For example if module B depends on module A and we want to build module B, Gradle will also build module A for us, because module B depends on it. But if we know for sure that module A is up to date and has not changed, we can also instruct Gradle to skip building module A, when we build module B.
Let's start with the following module structure, where each module depends on the module above it. So module services depends on common and module web depends on services:
