Migration Guide 3.2

@InjectMock

io.quakus.test.junit.mockito.InjectMock has been deprecated in favor of io.quarkus.test.InjectMock.

Native Compilation - Native executables and .so files

Due to changes made to GraalVM/Mandrel, if you are using an extension that is relying on .so files (such as the AWT extension), you need to add these .so files to the native container similarly to:

...
# Copy of the .so files to the container
COPY --chown=1001:root target/*.so /work/
COPY --chown=1001:root target/*-runner /work/application
...

Native Compilation - Work around missing CPU features

When building on recent machines and running your native executable on older machines, you may see the following failure when starting the application:

The current machine does not support all of the following CPU features that are required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA].
Please rebuild the executable with an appropriate setting of the -march option.

This error message means that the native compilation used more advanced instruction sets not supported by the CPU running the application. To work around that issue, add the following line to the application.properties:

quarkus.native.additional-build-args=-march=compatibility

Then, rebuild your native executable. This setting forces the native compilation to use an older instruction set, increasing the chance of compatibility.

To explicitly define the target architecture, run native-image -march=list to get the supported configurations and then set -march to one of them, e.g., quarkus.native.additional-build-args=-march=x86-64-v4. If you are targeting an AMD64 host, -march=x86-64-v2 would work in most cases.

Note	The march parameter is only available on GraalVM 23+.

Transaction manager (Narayana)

The configuration property quarkus.transaction-manager.object-store-directory has been renamed to quarkus.transaction-manager.object-store.directory.

Kubernetes

Improve the logic to generate TLS-based container ports

At the moment, the Kubernetes extension is always adding a container port called https to the generated Deployment resources. This approach is problematic because the port won’t work unless SSL is configured.

After 3.2, the container port https will not be added to the generated Deployment resources by default, unless: - Either users explicitly provide some of the quarkus.http.ssl.* properties at build time. - Or users add this property quarkus.kubernetes.ports.https.tls=true at build time.

More information about these changes in [here](https://github.com/quarkusio/quarkus/issues/33307).

Management interface port is not bound as a Service any longer

When the management port is enabled (see more information [here](https://quarkus.io/guides/management-interface-reference)), the Kubernetes extension will not generate the Kubernetes Service that binds the management port by default for security reasons.

Still, if you want to expose it via Service and Ingress resources, you can add the following properties:

quarkus.kubernetes.ingress.expose=true
quarkus.kubernetes.ingress.target-port=management

And now, a new Kubernetes Service will be generated to bind the Management interface port.