Grails normally will run any *Bootstrap classes at startup.
A Bootstrap class has a init and destroy closure.
The init closure is invoked during startup and destroy when the application stops.
The class name must end with Bootstrap and be placed in the grails-app/init folder.
Since Grails 3.2 we can skip the execution of Bootstrap classes by setting the Java system property grails.bootstrap.skip with the value true.
In the following example Bootstrap class we simply add a println to see the effect of using the system property grails.bootstrap.skip:
When we use the property syntax of Groovy to get the value for a property, Groovy will actually try to invoke a get method for that property if it is available.
So for example if we have the statement user.name actually user.getName() is invoked.
If we want to reference a property field directly, so bypassing the get method, we must place an @ in front of the property field name.
In the previous example we would write user.@name to get the field value directly.
The same rules apply for setting a value for a property with the Groovy syntax.
If we write user.name = 'mrhaki' then actually user.setName('mrhaki') is invoked.
We can use the @ prefix also to set a value without invoking the set method for that property.
So in our example it would be user.@name = 'mrhaki' and the setName method is not used.
In the following example we have a class Person with a name property.
We add a getName method which formats the name field and returns the value.
In a subclass User we access the name property from the super class using the Groovy property syntax and with the @ prefix:
In Asciidoctor we can add an anchor with an ID to a section or title and then reference it in a link.
The title of the section is used as link text.
We can alter that when we define the link, but if we rely on the default behaviour we create a title for our section including the caption label and number.
This way the created link points to the correct section and the text contains the caption text and number for that section.
In the following example markup we can see how we can use the caption label and section counter as attributes in the title.
We do this with the title attribute of a section.
By using the single quotes we tell Asciidoctor to interpret the attributes.
We must also make sure we set the caption attribute to an empty string value.
This disables the default caption creation of Asciidoctor for our section.
Finally we need to provide an ID for the section using the #ID syntax:
Asciidoctor has some built-in attributes to work with captions for certain content blocks.
For example the table-section attribute defines the caption label (by default Table) that is prefixed to a counter for all tables in the document.
When we transform our markup Asciidoctor will insert the text Table followed by the table number.
By default the caption for listing blocks is disabled, but we can easily enable it with the listing-caption attribute.
In the following markup we enable the caption for listing blocks and set the value to Listing.
This will add the text Listing followed by the listing section counter to the output.
Gradle has the built-in task wrapper to create a Gradle wrapper.
The Gradle wrapper can be part of our project so other people can build our project with Gradle, without the need for them to install Gradle.
Also if we specify the Gradle wrapper we can make sure the correct Gradle version is used.
To specify the version we must use the option --gradle-version.
This version can be different than the Gradle version we use to create the Gradle wrapper.
Since Gradle 3.1 we can also specify the distribution type of the Gradle wrapper.
We choose between a binary distribution or the all distribution, which contains documentation and source code.
Especially IDEs like to have the all distribution type, so they can provide better help in their editors.
With the following wrapper command we create a wrapper for Gradle 3.1 and the all distribution type.
For a binary distribution we either use the value bin or we don't specify the option, so Gradle falls back to the default value bin.
$ gradle wrapper --gradle-version 3.1 --distribution-type all
:wrapper
BUILD SUCCESSFUL
Total time: 1.012 secs
$
In Asciidoctor we can configure syntax highlighting for our source code listings.
We can choose from the built-in support for Coderay, Pygments, highlight.js and prettify.
The syntax highlighter libraries Coderay and Pygments support extra highlighting of lines, so we can add extra attention to those lines.
In this post we see how to use the line highlighting feature in Asciidoctor.
First we must add the document attribute source-highlighter and use the value coderay or pygments.
When we use Coderay we must also enable the line numbers for the source code listing, because Coderay will highlight the line numbers in the output.
Pygments highlight the whole line, with or without line numbers in the output.
Therefore we choose Pygments in our example.
To highlight certain lines in the source code output we use the highlight attribute for the source code block.
We can specify single line numbers separated by a comma (,) or semi colon (;).
If we use a comma we must enclose the value of the highlight attribute in quotes.
To define a range of line numbers we can define the start and end line numbers with a hyphen in between (eg. 5-10 to highlight lines 5 to 10).
To unhighlight a line we must prefix it with a exclamation mark (!).
For example the following value for the highlight attribute highlights the lines 2, 3 to 7 and not 5: [source,highlight=1;3-7;!5].
Although I couldn't make it to Gr8Conf EU this year, I am glad a lot of the presentations are available as slide decks and videos.
The slide deck for the talk Interesting nooks and crannies of Spock you (may) have never seen before by Marcin Zajączkowski is very interesting.
This is really a must read if you use Spock (and why shouldn't you) in your projects.
One of the interesting things is the ability to change the response for methods in a class that is stubbed using Spock's Stub method, but have no explicit stubbed method definition.
So normally when we create a stub we would add code that implements the methods from the stubbed class.
In our specification the methods we have written are invoked instead of the original methods from the stubbed class.
By default if we don't override a method definition, but it is used in the specification, Spock will try to create a response using a default response strategy.
The default response strategy for a stub is implemented by the class EmptyOrDummyResponse.
For example if a method has a return type Message then Spock will create a new instance of Message and return it to be used in the specification.
Spock also has a ZeroOrNullResponse response strategy.
With this strategy null is returned for our method that returns the Message type.
With Asciidoctor we can use images in our documents with the image directive.
When the document is converted each image gets a caption.
By default the caption label is Figure followed a number for the position of the image in the document.
So the first image has a caption Figure 1..
If we add a block title (text prefixed with a .) to the image then that text is used in the caption as well.
We can customize the caption label, figure counter, caption text or disable the figure caption using a combination of document and image attributes.
We have the following Asciidoctor markup.
We include several images and customize the figure caption settings.
To change the caption label (Figure) we set a different value for the document attribute figure-caption.
In our example we use the value Logo. Any captions following this definition will have the label Logo.
Asciidoctor has several captions and labels that can be overridden with document attributes.
We need to define a document attribute and assign a new value to override a default caption or label.
We can use UTF-8 characters as the value.
The following list shows captions and labels we can override:
When we use the include directive to include another document we can must make sure the included document fits the levels of our main document.
For example the included document shouldn't have level 0 headings if the main document already contains a level 0 heading.
We can change the level offset in the main document before including another document.
This will change the heading levels for the included document so all heading rules are okay.
To change the level offset we use the document attribute leveloffset.
It is best to use a relative value, so if the included document also contains included document the output will still be okay and the heading rules still apply.
Alternatively we can use the leveloffset attribute for the include directive.
In the following sample document we include other files with a level 0 heading:
