Quarkus 1.13 released - DevServices, Kubernetes Service Binding, OpenTelemetry

With Quarkus, our main goal is to make developer lives easier and bring back developer joy. In 1.13, we added a new element to the (not so secret) Quarkus recipe: DevServices.

When starting dev mode (live reload), we are now able to automatically start containers for your tests and you don’t even need to configure anything: the container is automatically wired to the Quarkus dev mode configuration.

For instance, if you’re developing a PostgreSQL-based application, as soon as you have the PostgreSQL JDBC extension in your pom, a container will be started for testing using Testcontainers.

You only need to define your configuration for production with the %prod. prefix. The dev mode one is taken care of.

You will find all the details about this new feature in the Datasource guide.

The OpenTelemetry project from the Cloud Native Computing Foundation is an initiative to merge the OpenTracing and OpenCensus projects to provide a common project for all telemetry. Tracing is the first piece of OpenTelemetry which GA’d in the last month, metrics and logging are still under development.

Quarkus 1.13 introduces a new extension for OpenTelemetry called quarkus-opentelemetry which offers the ability to trace requests. For exporting traces to a Jaeger collector, use the quarkus-opentelemetry-exporter-jaeger extension which depends on quarkus-opentelemetry. With this initial version, traces are available in JAX-RS Resource methods, REST Client, and Reactive Messaging with Kafka. Further integrations with other extensions will come in future releases, as well as a guide and quickstart.

Quarkus supports binding services to applications via the Service Binding Specification for Kubernetes. Specifically Quarkus implements the Application Projection part of the specification, thus allowing applications running in appropriately configured Kubernetes clusters to consume services (such as a Database or a Broker) without the need for user configuration.

Currently, the following Quarkus extensions support this feature:

This list of extensions will grow as more services with supported bindings become available on Kubernetes.

To enable Service Binding support, in addition to one of the currently supported extensions, the quarkus-kubernetes-service-binding extension needs to be added to the application dependencies.

Everything you need to know about it is detailed in the Kubernetes guide.

We are continuing to enrich the RESTEasy Reactive experience and, this time, it’s on the REST Client front. A new RESTEasy Reactive-based REST Client extension quarkus-rest-client-reactive is present in Quarkus 1.13.

Note that RESTEasy Reactive can be used for reactive but also for traditional blocking workloads.

Until now, if you wanted websockets support in your applications, you had to switch to Undertow.

Quarkus 1.13 introduces a pure-Vert.x-based Websockets extension called quarkus-websockets.

Given the way Quarkus is architected, it was not as easy as it should be to generate test coverage reports with Jacoco.

Quarkus 1.13 comes with quarkus-jacoco which will automatically generate your test coverage reports. And it does not require any Maven setup anymore. More about this in our updated guide.

@QuarkusIntegrationTest is the natural evolution of @NativeImageTest (which is still supported) and can be used to launch and test the artifact produced by the Quarkus build, and supports testing a jar (of all types), a native binary or container-image. For more information see this part of the documentation and the Javadoc of the annotation itself.

You can get the full changelogs of 1.13.0.CR1, and 1.13.0.Final on GitHub.