Great projects keep moving forward. JUnit5 is available since September 2017 and Spock 1.2 is already complete. Since Spock is based on JUnit4, I wondered what it would take to use Spock 1.2 together with JUnit5.
As it turns out, it’s quite easy to make that happen. JUnit5 comes with the vintage engine to run JUnit4 based tests. If that is available on the test classpath, your Spock tests run like on JUnit4.
Continue reading →
Making IntelliJ understand your QueryDSL generated classes needs some work.
QueryDSL has an annotation processor to generate Q-classes from your entities.
Just running the annotation processor doesn’t mean your IDE will understand where to find the generated classes.
I was struggling to get IntelliJ IDEA picking up the generated classes.
Probably there are more ways to get this done in Gradle, but I found out one that’s pretty easy to configure, without any adjustments to you IntelliJ settings.
Because you could configure the annotation processor via the IntelliJ settings in the Annotation Processor screen (Build, Execution, Deployment → Compiler → Annotation Processors).
It would be easier if you can achieve the same just using Gradle.
With the following in your Gradle build file, it generates the classes and instructs IntelliJ where to find the classes:
If you’re using Lombok in your entities, generating the QueryDSL classes will fail, as it won’t understand the Lombok annotations.
To solve this you have to add the Lombok dependency to the annotationProcessor block.
Continue reading →
Back in '98 when I started with my CS education Java was the first programming language we were taught.
Before I had experimented with QBasic, C and assembly but that was the moment where I started to really grow into being a software engineer.
While I made something excursions to other languages; PHP, C#, JavaScript and even ColdFusion, Java always was my 'base' where I returned to.
My great love as it were.
But now she’s fallen out of fashion and I’m moving on to greener pastures: Kotlin.
You might notice quite a big gap between this post and the previous one.
There are multiple reasons for this (a project taking up a lot of my energy is one of them), but a big reason is that in my personal projects I don’t really feel like using Java anymore, but on the other hand Java is the common theme in most of my posts here.
This is also reflected in the traffic my blog is getting; the "how to do X" type posts are the most popular.
My definitive move towards Kotlin started in November last year with the (awesome, check them out!) Advent of Code contest of 2017.
I use these to challenge myself to learn new things.
Back in 2015 I used the challenge to learn Scala and last year I started using Kotlin to solve the 2017 challenges (link if you want to check them out).
While doing the 2017 challenges I was actually having so much fun with Kotlin that I started working on the 2016 challenges as well!
Continue reading →
Micronaut makes it possible to easily configure your application using the provided mechanisms based on Spring and Grails.
This blog demonstrates how to configure a Kotlin based Micronaut application using Micronaut version 1.0.0.RC1.
First we create a Micronaut application featuring Kotlin:
After that we create our DemoController:
Continue reading →
Some time ago, I was working on a project where I had to fix an issue that was raised by our OWASP Zap scanner, which is a free security tool that runs in the test phase of the Jenkins build of the project.
It checks for security vulnerabilities that you want to prevent from going to Production.
Continue reading →
Jib is an open-source Java library from Google for creating Docker images for Java applications.
Jib can be used as Maven or Gradle plugin in our Spring Boot project.
One of the nice feature of Jib is that it adds layers with our classes, resources and dependency libraries for the Docker image.
This means that when only class files have changed, the classes layer is rebuild, but the others remain the same.
Therefore the creation of a Docker image with our Spring Boot application is also very fast (after the first creation).
Also the Maven and Gradle plugins have sensible defaults, like using the project name and version as image name, so we don’t have to configure anything in our build tool.
Although Jib provides options to configure other values for the defaults, for example to change the JVM options passed on to the application.
Let’s see Jib in action for a simple Spring Boot application.
In our example we use Gradle as build tool with the following Spring Boot application:
Continue reading →
Document attributes in Asciidoctor are very powerful.
We can assign values to a document attributes and reference the attribute name in our document enclosed between curly braces.
Asciidoctor will fill in the value when the document is transformed.
Instead of a plain value we can also use styling markup in the document attribute definition.
We must use the passthrough macro and allow for quote substitution.
In the following example document we define three document attributes: cl-added
, cl-updated
and cl-changed
.
We use the passthrough macro, quotes substation to assign CSS classes:
Continue reading →
When we use the Micronaut command line commands to generate controllers, beans and more, the classes will have a default package name.
We can use a fully qualified package name for the class we want to generate, but when we only define a class name, Micronaut will use a default package name automatically.
We can set the default package for an application when we first create an application with the create-app
command.
But we can also alter the default package name for an existing Micronaut application.
To set the default package name when we create a new application we must include the package name in our application name.
For example when we want to use the default package name mrhaki.micronaut
for an application that is called book-service
we must use the following create-app
command:
Continue reading →
In a previous post we learned how to add build information to the /info
endpoint in our application.
We can add custom information to the /info
endpoint via our application configuration or via a bean by implementing the InfoSource
interface.
Remember we need to add the io.micronaut:management
dependency to our application for this feature.
Any configuration property that is prefixed with info
will be exposed via the /info
endpoint.
We can define the properties in configuration files, using Java system properties or system environment variables.
In the following example configuration file we add the property info.sample.message
:
Continue reading →
One of the (many) great features of Micronaut is the HTTP client.
We use the @Client
annotation to inject a low-level HTTP client.
Or we define a declarative HTTP client based on an interface, for which Micronaut will generate an implementation.
The @Client
annotation supports the configuration
parameter to reference a configuration class with configuration properties for the HTTP client.
The configuration class extends HttpClientConfiguration
to support for example the configuration of timeouts and connection pooling.
We can add our own configuration properties as well and use them in our application.
In the following example we want to access the OpenWeatherMap API using a declarative HTTP client.
First we write a class that extends HttpClientConfiguration
.
This gives us HTTP client configuration properties and we also add some properties to define the OpenWeatherMap URI, path and access key we need to invoke the REST API.
Finally we add configuration properties for a @Retryable
annotation we want to use for our HTTP client.
Continue reading →
Writing tests is always a good idea when developing an application.
Micronaut makes it very easy to write tests.
Using the @Client
annotation we can generate a client for our REST resources that uses HTTP.
Starting up a Micronaut application is so fast we can run our actual application in our tests.
And using dependency injection we can replace components from the production application with stubs in our tests.
Let’s show how we can use stub in our tests for an example application.
In the example application we have controller ConferenceController
that returns Conference
objects.
These objects are fetched from a simple data repository ConferenceDataRepository
.
When we write a test we want to replace the ConferenceDataRepository
with a stub, so we can return the appropriate Conference
objects for our tests.
Continue reading →
Spring REST Docs is a project to document a RESTful API using tests.
The tests are used to invoke real REST calls on the application and to generate Asciidoctor markup snippets.
We can use the generated snippets in an Asciidoctor document with documentation about our API.
We can use Spring REST Docs to document a REST API we create using Micronaut.
First we must change our build file and include the Asciidoctor plugin and add dependencies to Spring REST Docs.
The following example Gradle build file adds the Gradle Asciidoctor plugin, Spring REST Docs dependencies and configures the test
and asciidoctor
tasks.
Spring REST Docs supports three different web clients to invoke the REST API of our application: Spring MockMVC, Spring Webflux WebTestClient and REST Assured.
We use REST Assured 3, because it has little dependencies on other frameworks (like Spring).
Continue reading →