Interesting links (week 43 2016)
Interesting links for week 42 2016:
Interesting links for week 42 2016:
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.
I recently wanted to do some source code analysis and found it difficult to find a good eclipse plugin. Luckily, it's now very easy to get your own SonarCube server running. Basically you only need a docker installation and a few simple steps. To start a SonarQube instance you run the following command:
docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 sonarqube
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:
:appendix-caption:
:caution-caption:
:example-caption:
:figure-caption:
:important-caption:
:last-update-label:
:manname-title:
:note-caption:
:table-caption:
:tip-caption:
:toc-title:
:untitled-label:
:version-label:
:warning-caption:
Interesting links for week 42 2016:
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:
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}
.
Having a Angular HTML5 single page application and a Spring Boot application, we would like to serve the complete Angular app from Spring Boot. This blog shows you a couple simple steps to get everything up and running: run NPM from Gradle, integrate the Gradle frontend build in the main build and support HTML5 mode in the ResourceHandler of Spring Boot.
Create a subdirectory called frontend
with the frontend code and build scripts (webpack, npm).
Let's assume our npm start
and npm run watch
output to the /frontend/dist/
directory.
First we need to make sure the frontend code is build when we run gradle build
on our project.
We can use the plugin gradle-node-plugin for this.
Go ahead and create a /frontend/build.gradle
file.