Asciidoctor has built-in support for a couple of source syntax highlighting libraries like Coderay, Pygments, highlight.js and prettify. In this post we learn how to use the Javascript library Prism to do the syntax highlighting for our source blocks. Because Prism is a Javascript library we must remember this only works for the HTML backend of Asciidoctor.
In the following markup we have two source code listings in Java and Groovy:
In Asciidoctor we can create a document attribute as a counter attribute. The attribute is automatically incremented each time we use it in our markup. We can choose to use numbers or characters. Only latin characters from 'a' to 'z' or 'A' to 'Z' are allowed. By default the counter will start at 1, but we can define another start value when we use the counter attribute for the first time.
To define a counter attribute we must prefix the attribute name with counter:.
Each time we use this syntax with the counter: prefix the value is incremented and displayed.
To only display the current value, without incrementing, we simply refer to the document attribute without the counter: prefix.
For example if we want to add a counter attribute with the name steps we would use the following markup in Asciidoctor: {counter:steps}.
With Asciidoctor we can use text to describe a symbol in our markup.
The text is automatically transformed to a Unicode replacement.
For example if we use the text (C) it is converted to © which is the copyright symbol: ©.
In the following sample we see all the symbol replacements:
Interesting links for week 41 2016:
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:
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:
Interesting links for week 40 2016:
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).
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:
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.
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:
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:
