Chapter 1. Compiling your Quarkus applications to native executables

1.1. Producing a native executable
リンクのコピー

A native binary is an executable that is created to run on a specific operating system (OS) or CPU architecture.

The following list outlines some examples of a native executable:

A universal binary for Mac
An ELF binary for Linux
An EXE binary for Windows

When you build a native executable, one advantage is that your application and dependencies, including the JVM, are packaged into a single file. The native executable for your application contains the following items:

The compiled application code
The Java APIs
The required libraries
A reduced version of the Java virtual machine (JVM) for improved application startup times and minimal disk and memory footprint

To produce a native executable from your Quarkus application, you can select either an in-container build or a local-host build. The following table explains the different building options that you can use:

Expand

Table 1.1. Building options for producing a native executable
Building option	Requires	Uses	Results in	Benefits
In-container build - Supported	A container runtime, for example, Podman or Docker	The default `registry.access.redhat.com/quarkus/mandrel-21-rhel8:21.3` builder image	A Linux 64-bit executable	GraalVM does not need to be set up locally, which makes your CI pipelines run more efficiently
Local-host build - Only supported upstream	A local installation of GraalVM or Mandrel	Its local installation as a default for the `quarkus.native.builder-image` property	An executable that has the same OS and CPU architecture as the machine on which the build is executed	An alternative for developers that are not allowed or don’t want to use tools such as Docker or Podman. Overall is faster than containers.

Important

Red Hat build of Quarkus supports the building of native Linux executables by using the Red Hat build of Quarkus Native builder, which is a productized distribution of Mandrel. Building native executables by using Oracle GraalVM Community Edition (CE), Mandrel community edition, or any other distributions of GraalVM is not supported for Red Hat build of Quarkus.

1.1.1. Producing a native executable by using an in-container build
リンクのコピー

To create a native executable and run the native image tests, use the native profile that is provided by Red Hat build of Quarkus for an in-container build.

Prerequisites

Podman or Docker is installed.
The container has access to at least 8GB of memory.

Procedure

Open the Getting Started project pom.xml file, and verify that the project includes the native profile:

<profiles>
    <profile>
        <id>native</id>
        <properties>
            <quarkus.package.type>native</quarkus.package.type>
        </properties>
    </profile>
</profiles>

<profiles>
    <profile>
        <id>native</id>
        <properties>
            <quarkus.package.type>native</quarkus.package.type>
        </properties>
    </profile>
</profiles>

Copy to Clipboard

Toggle word wrap

Build a native executable by using one of the following ways:
- Using Maven:
  - For Docker:
    
    ./mvnw package -Pnative -Dquarkus.native.container-build=true
    
    Copy to Clipboard Toggle word wrap
  - For Podman:
    
    ./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
    
    Copy to Clipboard Toggle word wrap
- Using the Quarkus CLI:
  - For Docker:
    
    quarkus build --native -Dquarkus.native.container-build=true
    
    Copy to Clipboard Toggle word wrap
  - For Podman:
    
    quarkus build --native -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
    
    Copy to Clipboard Toggle word wrap
    
    Step results
    These commands create a *-runner binary in the target directory, where the following is true:
  - The *-runner file is the built native binary produced by Quarkus.
  - The target directory is a directory that Maven creates when you build a Maven application.
    Important
    Compiling a Quarkus application to a native executable consumes a large amount of memory during analysis and optimization. You can limit the amount of memory used during native compilation by setting the quarkus.native.native-image-xmx configuration property. Setting low memory limits might increase the build time.
To run the native executable, enter the following command:
```
./target/*-runner
```
```
./target/*-runner
```
Copy to Clipboard Toggle word wrap

Additional resources

For more information, see 'Native executable configuration properties' in Compiling your Quarkus applications to native executables.

1.1.2. Producing a native executable by using a local-host build
リンクのコピー

If you are not using Docker or Podman, use the Quarkus local-host build option to create and run a native executable.

Using the local-host build approach is faster than using containers and is suitable for machines that use a Linux operating system.

Important

Using the following procedure in production is not supported by Quarkus. Use this method only when testing or as a backup approach when Docker or Podman is not available.

Prerequisites

A local installation of Mandrel or GraalVm, correctly configured according to the Building a native executable guide.
- Additionally, for a GraalVM installation, native-image must also be installed.

Procedure

For GraalVM or Mandrel, build a native executable by using one of the following ways:
- Using Maven:
  ./mvnw package -Pnative
  Copy to Clipboard Toggle word wrap
- Using the Quarkus CLI:
  quarkus build --native
  Copy to Clipboard Toggle word wrap
  Step results
  These commands create a *-runner binary in the target directory, where the following is true:
  - The *-runner file is the built native binary produced by Quarkus.
  - The target directory is a directory that Maven creates when you build a Maven application.
    Note
    When you build the native executable, the prod profile is enabled unless modified in the quarkus.profile property.
Run the native executable:
```
./target/*-runner
```
```
./target/*-runner
```
Copy to Clipboard Toggle word wrap
Note
- Native tests run using the prod profile by default unless modified in the quarkus.test.native-image-profile property.

Additional resources

For more information, see Producing a native executable.

1.2. Creating a custom container image
リンクのコピー

You can create a container image from your Quarkus application using one of the following methods:

Creating a container manually
Creating a container using the OpenShift Docker build

Important

Compiling a Quarkus application to a native executable consumes a large amount of memory during analysis and optimization. You can limit the amount of memory used during native compilation by setting the quarkus.native.native-image-xmx configuration property. Setting low memory limits might increase the build time.

1.2.1. Creating a container manually
リンクのコピー

This section shows you how to manually create a container image with your application for Linux AMD64. When you produce a native image by using the Quarkus Native container, the native image creates an executable that targets Linux AMD64. If your host operating system is different from Linux AMD64, you cannot run the binary directly and you need to create a container manually.

Your Quarkus Getting Started project includes a Dockerfile.native in the src/main/docker directory with the following content:

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
WORKDIR /work/
RUN chown 1001 /work \
    && chmod "g+rwX" /work \
    && chown 1001:root /work
COPY --chown=1001:root target/*-runner /work/application

EXPOSE 8080
USER 1001

CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
WORKDIR /work/
RUN chown 1001 /work \
    && chmod "g+rwX" /work \
    && chown 1001:root /work
COPY --chown=1001:root target/*-runner /work/application

EXPOSE 8080
USER 1001

CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

Copy to Clipboard

Toggle word wrap

Note

Universal Base Image (UBI)

The following list displays the suitable images for use with Dockerfiles.

Red Hat Universal Base Image 8 (UBI8). This base image is designed and engineered to be the base layer for all of your containerized applications, middleware, and utilities.
```
registry.access.redhat.com/ubi8/ubi:8.5
```
```
registry.access.redhat.com/ubi8/ubi:8.5
```
Copy to Clipboard Toggle word wrap
Red Hat Universal Base Image 8 Minimal (UBI8-minimal). A stripped-down UBI8 image that uses microdnf as a package manager.
```
registry.access.redhat.com/ubi8/ubi-minimal:8.5
```
```
registry.access.redhat.com/ubi8/ubi-minimal:8.5
```
Copy to Clipboard Toggle word wrap
All Red Hat Base images are available on the Container images catalog site.

Procedure

Build a native Linux executable by using one of the following methods:

Docker:

./mvnw package -Pnative -Dquarkus.native.container-build=true

./mvnw package -Pnative -Dquarkus.native.container-build=true

Copy to Clipboard

Toggle word wrap

Podman:

./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman

./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman

Copy to Clipboard

Toggle word wrap

Build the container image by using one of the following methods:

Docker:

docker build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .

docker build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .

Copy to Clipboard

Toggle word wrap

Podman

podman build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .

podman build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .

Copy to Clipboard

Toggle word wrap

Run the container by using one of the following methods:

Docker:

docker run -i --rm -p 8080:8080 quarkus-quickstart/getting-started

docker run -i --rm -p 8080:8080 quarkus-quickstart/getting-started

Copy to Clipboard

Toggle word wrap

Podman:

podman run -i --rm -p 8080:8080 quarkus-quickstart/getting-started

podman run -i --rm -p 8080:8080 quarkus-quickstart/getting-started

Copy to Clipboard

Toggle word wrap

1.2.2. Creating a container using the OpenShift Docker build
リンクのコピー

You can create a container image for your Quarkus application using the OpenShift Docker build strategy. This strategy creates a container image by using a build configuration in the cluster.

Prerequisites

You have access to a Red Hat OpenShift Container Platform cluster and the latest version of the OpenShift CLI (oc) is installed. For information about installing oc, see the Installing the CLI section of the Installing and configuring OpenShift Container Platform clusters guide.
A URL for the OpenShift API endpoint.

Procedure

Log in to the OpenShift CLI:
```
oc login -u <username_url>
```
```
oc login -u <username_url>
```
Copy to Clipboard Toggle word wrap
Create a new project in OpenShift:
```
oc new-project <project_name>
```
```
oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap

Create a build config based on the src/main/docker/Dockerfile.native file:

cat src/main/docker/Dockerfile.native | oc new-build --name <build_name> --strategy=docker --dockerfile -

cat src/main/docker/Dockerfile.native | oc new-build --name <build_name> --strategy=docker --dockerfile -

Copy to Clipboard

Toggle word wrap

Build the project:

oc start-build <build_name> --from-dir .

oc start-build <build_name> --from-dir .

Copy to Clipboard

Toggle word wrap

Deploy the project to OpenShift:
```
oc new-app <build_name>
```
```
oc new-app <build_name>
```
Copy to Clipboard Toggle word wrap
Expose the services:
```
oc expose svc/<build_name>
```
```
oc expose svc/<build_name>
```
Copy to Clipboard Toggle word wrap

1.3. Native executable configuration properties
リンクのコピー

Configuration properties define how the native executable is generated. You can configure your Quarkus application using the application.properties file.

Configuration properties

The following table lists the configuration properties that you can set to define how the native executable is generated:

Expand

Property	Description	Type	Default
`quarkus.native.compression.additional-args`	Allows passing extra arguments to the UPX command line (like --brute). The arguments are comma-separated. The exhaustive list of parameters can be found in `https://github.com/upx/upx/blob/devel/doc/upx.pod`.	list of strings
`quarkus.native.compression.level`	The compression level in [1, 10]. 10 means best. Higher compression level requires more time to compress the executable.	int
`quarkus.native.debug.enabled`	If debug is enabled and debug symbols are generated. The symbols will be generated in a separate `.debug` file.	boolean	false
`quarkus.native.resources.excludes`	A comma separated list of globs to match resource paths that should not be added to the native image.	list of strings
`quarkus.native.additional-build-args`	Additional arguments to pass to the build process.	list of strings
`quarkus.native.enable-http-url-handler`	Enables HTTP URL handler. This allows you to do `URL.openConnection()` for HTTP URLs.	boolean	`true`
`quarkus.native.enable-https-url-handler`	Enables HTTPS URL handler. This allows you to do `URL.openConnection()` for HTTPS URLs.	boolean	`false`
`quarkus.native.enable-all-security-services`	Adds all security services to the native image.	boolean	`false`
`quarkus.native.add-all-charsets`	Adds all character sets to the native image. This increases the image size.	boolean	`false`
`quarkus.native.graalvm-home`	Contains the path of the GraalVM distribution.	string	`${GRAALVM_HOME:}`
`quarkus.native.java-home`	Contains the path of the JDK.	File	`${java.home}`
`quarkus.native.native-image-xmx`	The maximum Java heap used to generate the native image.	string
`quarkus.native.debug-build-process`	Waits for a debugger to attach to the build process before running the native image build. This is an advanced option for those familiar with GraalVM internals.	boolean	`false`
`quarkus.native.publish-debug-build-process-port`	Publishes the debug port when building with docker if `debug-build-process` is `true`.	boolean	`true`
`quarkus.native.cleanup-server`	Restarts the native image server.	boolean	`false`
`quarkus.native.enable-isolates`	Enables isolates to improve memory management.	boolean	`true`
`quarkus.native.enable-fallback-images`	Creates a JVM-based fallback image if the native image fails.	boolean	`false`
`quarkus.native.enable-server`	Uses the native image server. This can speed up compilation but can result in lost changes due to cache invalidation issues.	boolean	`false`
`quarkus.native.auto-service-loader-registration`	Automatically registers all `META-INF/services` entries.	boolean	`false`
`quarkus.native.dump-proxies`	Dumps the bytecode of all proxies for inspection.	boolean	`false`
`quarkus.native.container-build`	Builds using a container runtime. Docker is used by default.	boolean	`false`
`quarkus.native.builder-image`	The docker image to build the image.	string	`registry.access.redhat.com/quarkus/mandrel-21-rhel8:21.3`
`quarkus.native.container-runtime`	The container runtime used build the image. For example, Docker.	string
`quarkus.native.container-runtime-options`	Options to pass to the container runtime.	list of strings
`quarkus.native.enable-vm-inspection`	Enables VM introspection in the image.	boolean	`false`
`quarkus.native.full-stack-traces`	Enables full stack traces in the image.	boolean	`true`
`quarkus.native.enable-reports`	Generates reports on call paths and included packages/classes/methods.	boolean	`false`
`quarkus.native.report-exception-stack-traces`	Reports exceptions with a full stack trace.	boolean	`true`
`quarkus.native.report-errors-at-runtime`	Reports errors at runtime. This may cause your application to fail at runtime if you use unsupported features.	boolean	`false`
`quarkus.native.resources.includes`	A comma-separated list of globs to match resource paths that should be added to the native image. Use a slash (`/`) character as a path separator on all platforms. Globs must not start with a slash. For example, if you have `src/main/resources/ignored.png` and `src/main/resources/foo/selected.png` in your source tree and one of your dependency JARs contains a `bar/some.txt` file, with `quarkus.native.resources.includes` set to `foo/,bar//*.txt`, the files `src/main/resources/foo/selected.png` and `bar/some.txt` will be included in the native image, while `src/main/resources/ignored.png` will not be included. For more information, see the following table, which lists the supported glob features.	list of strings
`quarkus.native.debug.enabled`	Enables debug and generates debug symbols in a separate `.debug` file. When used with `quarkus.native.container-build`, Red Hat build of Quarkus only supports Red Hat Enterprise Linux or other Linux distributions as they contain the `binutils` package that installs the `objcopy` utility that splits the debug info from the native image.	boolean	`false`

Supported glob features

The following table lists the supported glob features and descriptions:

Expand

Character	Feature description
`*`	Matches a possibly-empty sequence of characters that does not contain slash (`/`).
`**`	Matches a possibly-empty sequence of characters that might contain slash (`/`).
`?`	Matches one character, but not slash.
`[abc]`	Matches one character specified in the bracket, but not slash.
`[a-z]`	Matches one character from the range specified in the bracket, but not slash.
`[!abc]`	Matches one character not specified in the bracket; does not match slash.
`[!a-z]`	Matches one character outside the range specified in the bracket; does not match slash.
`{one,two,three}`	Matches any of the alternating tokens separated by commas; the tokens may contain wildcards, nested alternations, and ranges.
`\`	The escape character. There are three levels of escaping: `application.properties` parser, MicroProfile Config list converter, and Glob parser. All three levels use the backslash as the escape character.

1.3.1. Configuring memory consumption for Quarkus native compilation
リンクのコピー

Compiling a Quarkus application to a native executable consumes a large amount of memory during analysis and optimization. You can limit the amount of memory used during native compilation by setting the quarkus.native.native-image-xmx configuration property. Setting low memory limits might increase the build time.

Procedure

Use one of the following methods to set a value for the quarkus.native.native-image-xmx property to limit the memory consumption during the native image build time:
- Using the application.properties file:
  quarkus.native.native-image-xmx=<maximum_memory>
  Copy to Clipboard Toggle word wrap
- Setting system properties:
  mvn -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.native-image-xmx=<maximum_memory>
  Copy to Clipboard Toggle word wrap
  This command builds the native executable with Docker. To use Podman, add the -Dquarkus.native.container-runtime=podman argument.

Note

For example, to set the memory limit to 6 GB, enter quarkus.native.native-image-xmx=6g. The value must be a multiple of 1024 and greater than 2MB. Append the letter m or M to indicate megabytes, or g or G to indicate gigabytes.

1.4. Testing the native executable
リンクのコピー

Test the application in native mode to test the functionality of the native executable. Use the @NativeImageTest annotation to build the native executable and run tests against the HTTP endpoints.

Procedure

Open the pom.xml file and verify that the native profile has the following elements:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>${surefire-plugin.version}</version>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
            <configuration>
                <systemPropertyVariables>
                    <native.image.path>${project.build.directory}/${project.build.finalName}-runner</native.image.path>
                    <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
                    <maven.home>${maven.home}</maven.home>
                </systemPropertyVariables>
            </configuration>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>${surefire-plugin.version}</version>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
            <configuration>
                <systemPropertyVariables>
                    <native.image.path>${project.build.directory}/${project.build.finalName}-runner</native.image.path>
                    <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager>
                    <maven.home>${maven.home}</maven.home>
                </systemPropertyVariables>
            </configuration>
        </execution>
    </executions>
</plugin>

Copy to Clipboard

Toggle word wrap

The Maven Failsafe plug-in (maven-failsafe-plugin) runs the integration test and also indicates the location of the native executable that is generated.

Open the src/test/java/org/acme/quickstart/NativeGreetingResourceIT.java file and verify that it includes the following content:
```
package org.acme.quickstart;


import io.quarkus.test.junit.NativeImageTest;

@NativeImageTest 
public class NativeGreetingResourceIT extends GreetingResourceTest { 

    // Run the same tests

}
```
```
package org.acme.quickstart;


import io.quarkus.test.junit.NativeImageTest;

@NativeImageTest 
```
1
```
public class NativeGreetingResourceIT extends GreetingResourceTest { 
```
2
```
    // Run the same tests

}
```
Copy to Clipboard Toggle word wrap
1
Use another test runner that starts the application from the native file before the tests. The executable is retrieved by using the native.image.path system property configured in the Maven Failsafe plug-in.
2
This example extends the GreetingResourceTest, but you can also create a new test.

Run the test:

./mvnw verify -Pnative

./mvnw verify -Pnative

Copy to Clipboard

Toggle word wrap

The following example shows the output of this command:

./mvnw verify -Pnative
...
[getting-started-1.0-SNAPSHOT-runner:18820]     universe:     587.26 ms
[getting-started-1.0-SNAPSHOT-runner:18820]      (parse):   2,247.59 ms
[getting-started-1.0-SNAPSHOT-runner:18820]     (inline):   1,985.70 ms
[getting-started-1.0-SNAPSHOT-runner:18820]    (compile):  14,922.77 ms
[getting-started-1.0-SNAPSHOT-runner:18820]      compile:  20,361.28 ms
[getting-started-1.0-SNAPSHOT-runner:18820]        image:   2,228.30 ms
[getting-started-1.0-SNAPSHOT-runner:18820]        write:     364.35 ms
[getting-started-1.0-SNAPSHOT-runner:18820]      [total]:  52,777.76 ms
[INFO]
[INFO] --- maven-failsafe-plugin:2.22.1:integration-test (default) @ getting-started ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.quickstart.NativeGreetingResourceIT
Executing [/data/home/gsmet/git/quarkus-quickstarts/getting-started/target/getting-started-1.0-SNAPSHOT-runner, -Dquarkus.http.port=8081, -Dtest.url=http://localhost:8081, -Dquarkus.log.file.path=build/quarkus.log]
2019-04-15 11:33:20,348 INFO  [io.quarkus] (main) Quarkus 999-SNAPSHOT started in 0.002s. Listening on: http://[::]:8081
2019-04-15 11:33:20,348 INFO  [io.quarkus] (main) Installed features: [cdi, resteasy]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.387 s - in org.acme.quickstart.NativeGreetingResourceIT
...

./mvnw verify -Pnative
...
[getting-started-1.0-SNAPSHOT-runner:18820]     universe:     587.26 ms
[getting-started-1.0-SNAPSHOT-runner:18820]      (parse):   2,247.59 ms
[getting-started-1.0-SNAPSHOT-runner:18820]     (inline):   1,985.70 ms
[getting-started-1.0-SNAPSHOT-runner:18820]    (compile):  14,922.77 ms
[getting-started-1.0-SNAPSHOT-runner:18820]      compile:  20,361.28 ms
[getting-started-1.0-SNAPSHOT-runner:18820]        image:   2,228.30 ms
[getting-started-1.0-SNAPSHOT-runner:18820]        write:     364.35 ms
[getting-started-1.0-SNAPSHOT-runner:18820]      [total]:  52,777.76 ms
[INFO]
[INFO] --- maven-failsafe-plugin:2.22.1:integration-test (default) @ getting-started ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.quickstart.NativeGreetingResourceIT
Executing [/data/home/gsmet/git/quarkus-quickstarts/getting-started/target/getting-started-1.0-SNAPSHOT-runner, -Dquarkus.http.port=8081, -Dtest.url=http://localhost:8081, -Dquarkus.log.file.path=build/quarkus.log]
2019-04-15 11:33:20,348 INFO  [io.quarkus] (main) Quarkus 999-SNAPSHOT started in 0.002s. Listening on: http://[::]:8081
2019-04-15 11:33:20,348 INFO  [io.quarkus] (main) Installed features: [cdi, resteasy]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.387 s - in org.acme.quickstart.NativeGreetingResourceIT
...

Copy to Clipboard

Toggle word wrap

Note

Quarkus waits for 60 seconds for the native image to start before automatically failing the native tests. You can change this duration by configuring the quarkus.test.wait-time system property.

You can extend the wait time by using the following command where <duration> is the wait time in seconds:

./mvnw verify -Pnative -Dquarkus.test.wait-time=<duration>

./mvnw verify -Pnative -Dquarkus.test.wait-time=<duration>

Copy to Clipboard

Toggle word wrap

1.4.1. Excluding tests when running as a native executable
リンクのコピー

When you run tests against your native application, you can only interact with its HTTP endpoints. Because tests do not run natively, you cannot link against your application’s code like you do when running tests on the JVM.

You can share your test class between your JVM and native executions and exclude certain tests using the @DisabledOnNativeImage annotation to run tests only on the JVM.

1.4.2. Testing an existing native executable
リンクのコピー

By using the Failsafe Maven plug-in, you can test against the existing executable build. You can run multiple sets of tests in stages on the binary after it is built.

Note

To test the native executable that you produced with Quarkus, use the available Maven commands. There are no equivalent Quarkus CLI commands to complete this task by using the command line.

Procedure

Run a test against a native executable that is already built:
```
./mvnw test-compile failsafe:integration-test
```
```
./mvnw test-compile failsafe:integration-test
```
Copy to Clipboard Toggle word wrap
This command runs the test against the existing native image by using the Failsafe Maven plug-in.
Alternatively, you can specify the path to the native executable with the following command where <path> is the native image path:
```
./mvnw test-compile failsafe:integration-test -Dnative.image.path=<path>
```
```
./mvnw test-compile failsafe:integration-test -Dnative.image.path=<path>
```
Copy to Clipboard Toggle word wrap

このコンテンツは選択した言語では利用できません。

1.1. Producing a native executable
リンクのコピー

1.1.1. Producing a native executable by using an in-container build
リンクのコピー

1.1.2. Producing a native executable by using a local-host build
リンクのコピー

1.2. Creating a custom container image
リンクのコピー

1.2.1. Creating a container manually
リンクのコピー

1.2.2. Creating a container using the OpenShift Docker build
リンクのコピー

1.3. Native executable configuration properties
リンクのコピー

1.3.1. Configuring memory consumption for Quarkus native compilation
リンクのコピー

1.4. Testing the native executable
リンクのコピー

1.4.1. Excluding tests when running as a native executable
リンクのコピー

1.4.2. Testing an existing native executable
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

このコンテンツは選択した言語では利用できません。

Chapter 1. Compiling your Quarkus applications to native executables

1.1. Producing a native executableリンクのコピーリンクがクリップボードにコピーされました!

1.1.1. Producing a native executable by using an in-container buildリンクのコピーリンクがクリップボードにコピーされました!

1.1.2. Producing a native executable by using a local-host buildリンクのコピーリンクがクリップボードにコピーされました!

1.2. Creating a custom container imageリンクのコピーリンクがクリップボードにコピーされました!

1.2.1. Creating a container manuallyリンクのコピーリンクがクリップボードにコピーされました!

1.2.2. Creating a container using the OpenShift Docker buildリンクのコピーリンクがクリップボードにコピーされました!

1.3. Native executable configuration propertiesリンクのコピーリンクがクリップボードにコピーされました!

1.3.1. Configuring memory consumption for Quarkus native compilationリンクのコピーリンクがクリップボードにコピーされました!

1.4. Testing the native executableリンクのコピーリンクがクリップボードにコピーされました!

1.4.1. Excluding tests when running as a native executableリンクのコピーリンクがクリップボードにコピーされました!

1.4.2. Testing an existing native executableリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.1. Producing a native executable
リンクのコピー

1.1.1. Producing a native executable by using an in-container build
リンクのコピー

1.1.2. Producing a native executable by using a local-host build
リンクのコピー

1.2. Creating a custom container image
リンクのコピー

1.2.1. Creating a container manually
リンクのコピー

1.2.2. Creating a container using the OpenShift Docker build
リンクのコピー

1.3. Native executable configuration properties
リンクのコピー

1.3.1. Configuring memory consumption for Quarkus native compilation
リンクのコピー

1.4. Testing the native executable
リンクのコピー

1.4.1. Excluding tests when running as a native executable
リンクのコピー

1.4.2. Testing an existing native executable
リンクのコピー