Normally when using swagger, you generate a swagger.yaml file for your API. But what if you already have a swagger.yaml file and you want to generate the API interface and models, like you would also do with a webservice using a WSDL file? To achieve this, swagger has a great tool: swagger-codegen. The tool has a CLI and a maven plugin, but no gradle plugin. So how do we use it with gradle?

Defining tables in Asciidoctor is very easy. The start and end of the table are defined by |===. But if we want to add a new table to a table cell we cannot use the same syntax. To define a nested table we must replace the | separator with !. So instead of |=== to indicate the table boundaries we use !===. Also the cell separators are now ! instead of |. Finally we must make sure the table cell or column supports Asciidoc markup, so the table is properly created. We must configure the cell or column with a so the nested table is created.

In the following example Asciidoctor markup we have a simple table with a nested table in the second column and row. Notice we can still apply all table configuration to the nested table as well:

Gradle has incremental build support to speed up our builds. This means Gradle checks input and output for a task and if something changed the task is executed, otherwise the task is skipped. In previous posts we learned how to add incremental build support to our tasks with annotations and inputs and outputs property of a task. When we have a task that has an output file for an input file, like with transformations, we can have a more efficient task using an incremental task action. With an incremental task action we have extra information on the files that are handled by the task. We can have different actions based on if an input file is out of date or removed. This way we can handle only the input files that have changed or removed with incremental builds, instead of all the input files.

To create an incremental task action we must have a task action method (annotated with @TaskAction) that has a single argument of type IncrementalTaskInputs. The IncrementalTaskInputs class has the method outOfDate and removed. These methods take an action, that can be implemented with a closure, with an instance of InputFileDetails as argument. We can get to the input file via this instance and use that for our task logic. When an input file is out of date, because the file contents has changed or the output file has been removed, the action we defined for the outOfDate method is invoked. If the input file is removed the action for the method removed is invoked.

Gradle 3.5 introduced the build cache. With the build cache we can reuse task output from builds that can come from different computers. We can also use the build cache feature for our local builds. By default the directory to store the cache is located in the Gradle user home directory on our computer (USER_HOME/.gradle/caches/build-cache-1). We can change the directory for the local cache via settings.gradle of our Gradle project. For example we could configure a directory in our project file structure to be the build cache directory. Then it is easy to clean the cache, because it is a directory not shared by other Gradle projects. With the default directory location in the Gradle user home directory the caches of all Gradle projects we run on our computer are stored in a single directory. And the cache doesn’t shrink and will only grow we might want to have more control of where the cache of a single Gradle project is stored. This way we can easily clean the cache, because all files of a project are stored in the directory for that project.

In the following example settings.gradle file we configure our build cache directory to be the directory build-cache in the root directory of our project where we store our settings.gradle file:

Gradle 3.5 introduced the build cache. With the build cache we can share task output between builds on different computers. For example the build output from a continuous integration server can be used on a developer’s computer. To use the build cache feature we use the command-line option --build-cache. Instead of using the command-line option --build-cache we can set the Gradle property org.gradle.caching with the value true in the file gradle.properties of our project. To set this property for all our projects we set the property in the gradle.properties file in the Gradle home directory, which is usually at USER_HOME/.gradle/gradle.properties.

In the following example we set the property org.gradle.caching in ~/.gradle/gradle.properties:

Since the introduction of the Jenkins Declarative Pipeline syntax (as opposed to the Scripted Pipeline syntax) the concept of a shared library has become more important as we are otherwise restricted to the sections of the pipeline model. So we’ll make a basic set-up with a call to a defined step in a shared library.

A shared library called "jdriven" is configured globally in Jenkins (see link to jenkins.io at the end on how to do that). It has a defined step showQuote defined in it’s own file on branch "blog/shared-lib-example"

Writing protractor tests can be quite difficult, because of all the asynchronous calls you have to deal with. Even promise-chaining does not help when your tests become longer and more complex. With Javascript generator functions it is possible to simplify your tests.

We can use Spring Boot Actuator to add endpoints to our application that can expose information about our application. For example we can request the /env endpoint to see which Spring environment properties are available. Or use /configprops to see the values of properties defined using @ConfigurationProperties. Sensitive information like passwords and keys are replaced with . Spring Boot Actuator has a list of properties that have sensitive information and therefore should be replaced with . The default list of keys that have their value hidden is defined as password,secret,key,token,.credentials.,vcap_services. A value is either what the property name ends with or a regular expression. We can define our own list of property names from which the values should be hidden or sanitized and replaced with . We define the key we want to be hidden using the application properties endpoints.env.keys-to-sanatize and endpoints.configprops.keys-to-sanatize.

In the following example Spring application YAML configuration we define new values for keys we want to be sanitized. Properties in our Spring environment that end with username or password should be sanatized. For properties set via @ConfigurationProperties we want to hide values for keys that end with port and key:

When we write a feature method in our Spock specification to test our class we might run into long running methods that are invoked. We can specify a maximum time we want to wait for a method. If the time spent by the method is more than the maximum time our feature method must fail. Spock has the @Timeout annotation to define this. We can apply the annotation to our specification or to feature methods in the specification. We specify the timeout value as argument for the @Timeout annotation. Seconds are the default time unit that is used. If we want to specify a different time unit we can use the annotation argument unit and use constants from java.util.concurrent.TimeUnit to set a value.

In the following example specification we set a general timeout of 1 second for the whole specification. For two methods we override this default timeout with their own value and unit:

To ignore feature methods in our Spock specification we can use the annotation @Ignore. Any feature method or specification with this annotation is not invoked when we run a specification. With the annotation @IgnoreRest we indicate that feature methods that do not have this annotation must be ignored. So any method with the annotation is invoked, but the ones without aren’t. This annotation can only be applied to methods and not to a specification class.

In the next example we have a specification with two feature methods that will be executed and one that is ignored:

On my current project we use Java 8, Spring 4.3 and Tomcat 7.0 as application server. After the scheduling functionality was added to the project the application server did not shut down any more, it hung till the end of time. I like to use the default Java implementations when possible so the configured scheduler was the java.util.concurrent.ScheduledThreadPoolExecutor.

After some investigation we found out that the application server did not shutdown because the created ScheduledExecutorService bean did not stop. The threads in the thread pool didn’t stop when the application context is destroyed. The destroyMethod is defined and Spring calls the shutdown method but it still did not stop the application server. When I tested with Spring Boot it shuts down without a problem. Spring has also their own ThreadPoolTaskScheduler with much more configuration options. Strangely it does not implement the same interface java.util.concurrent.ScheduledExecutorService as I would expect from the Spring framework but you can use both implementations.

In a modern service landscape, especially when using containers, you are probably using something like the ELK stack (Elasticsearch, Logstash, Kibana) to flow all the logging into. But how to find from all those loglines what caused the nasty bug after a innocent buttonpress? One of the easy answers to this is what’s called a correlation id - basically a unique number assigned to that buttonpress which gets carried around between the services and added to every logline. Sounds good you say? it is so let’s see how to do this.