Quarkus Package Type
Gwenda Gronert
Use Maven to create a new project, add or remove extensions, launch development mode, debug your application, and build your application into a jar, native executable, or container-friendly executable. Import your project into your favorite IDE using Maven project metadata.
If you need to customize the compiler flags used by the plugin, like in development mode, add a configuration section to the plugin block and set the compilerArgs property just as you would when configuring maven-compiler-plugin.You can also set source, target, and jvmArgs.For example, to pass --enable-preview to both the JVM and javac:
Because the Quarkus Maven plugin itself runs in the JVM started by Maven,and because some (rare) Quarkus extensions need to load application classes during the build,it may be necessary to pass the same flags to the JVM running Maven.
Alternatively, you can simply create the file.mvn/jvm.config at the root of your project:and any options you put in that file will be picked up by Maven, without having to set MAVEN_OPTS.
You can then update the application sources, resources and configurations.The changes are automatically reflected in your running application.This is great to do development spanning UI and database as you see changes reflected immediately.
Dev mode enables hot deployment with background compilation, which meansthat when you modify your Java files or your resource files and refresh your browser these changes will automatically take effect.This works too for resource files like the configuration property file.The act ofrefreshing the browser triggers a scan of the workspace, and if any changes are detected the Java files are compiled,and the application is redeployed, then your request is serviced by the redeployed application. If there are any issueswith compilation or deployment an error page will let you know.
Now every time you refresh the browser you should see any changes you have made locally immediately visible in the remoteapp. This is done via an HTTP based long polling transport, that will synchronize your local workspace and the remoteapplication via HTTP calls.
If you do not want to use the HTTP feature then you can simply run the remote-dev command without specifying the URL.In this mode the command will continuously rebuild the local application, so you can use an external tool such as odo orrsync to sync to the remote application.
Whether Quarkus should enable its ability to not do a full restart when changes to classes are compatible with JVM instrumentation. If this is set to true, Quarkus will perform class redefinition when possible.
Usually, dependencies of an application (which is a Maven project) could be displayed using mvn dependency:tree command. In case of a Quarkus application, however, this command will list only the runtime dependencies of the application.Given that the Quarkus build process adds deployment dependencies of the extensions used in the application to the original application classpath, it could be useful to know which dependencies and which versions end up on the build classpath.Luckily, the quarkus Maven plugin includes the dependency-tree goal which displays the build dependency tree for the application.
When building an Uber-Jar you can specify entries that you want to exclude from the generated jar by using the quarkus.package.ignored-entries configurationoption, this takes a comma separated list of entries to ignore.
By default the generated uber JAR file name will have the -runner suffix, unless it was overriden by configuring a custom one with quarkus.package.runner-suffix configuration option.If the runner suffix is not desired, it can be disabled by setting quarkus.package.jar.add-runner-suffix configuration option to false, in which case the uber JAR will replace the original JARfile generated by maven-jar-plugin for the application module.
As long as an Uber-Jar file name is created by appending a suffix, such as runner, to the original project JAR file name, the Uber-Jar file name suffix will also be used as the Mavenartifact classifier for the Uber-Jar artifact. There are two ways to attach an Uber-Jar as the main project artifact (without the classifier):
The best way to enable CDI bean discovery for a module in a multi-module project would be to include the jandex-maven-plugin,unless it is the main application module already configured with the quarkus-maven-plugin, in which case it will be indexed automatically.
The reason is that, Quarkus may need to re-resolve application dependencies during the test phase to set up the test classpath for the tests. The original Maven resolver used in previous build phaseswill not be available in the test process and, as a conseqence, Quarkus will need to initialize a new one. To make sure the new resolver is initialized correctly, the relevant configuration optionswill need to be passed to the test process.
A path to the Maven user settings file may need to be passed to test processes, for example, in case the Maven build process was not launched using the default mvn scripts included in the Maven distribution.It could be done in the following way:
However, it is also possible to specify the profile directly in the POM file of the project using project properties, the Quarkus Maven plugin configuration properties or system properties set in the Quarkus Maven plugin configuration.
In some particular use cases, it can be interesting to build several artifacts of your application from the same module.A typical example is when you want to build your application with different configuration profiles.
Below is an example of a Quarkus Maven plugin configuration that will produce two builds of the same application: one using the prod-oracle profile and the other one using the prod-postgresql profile.
To isolate profile-specific dependencies from other profiles, the JDBC drivers could be added as optional dependencies to the application but configured to be included in each profile that requires them, e.g.:
With the classifier and type being optional (note that the brackets ([]) denote optionality and are not a part of the syntax specification). The group ID and artifact ID must be present and non-empty.
Indicates whether the generated JAR file should have the runner suffix appended. Only applicable to the JarType#UBER_JAR uber-JAR output type. If disabled, the JAR built by the original build system (Maven, Gradle, etc.) will be replaced with the Quarkus-built uber-JAR.
Whether to automate the creation of AppCDS. Furthermore, this option only works for Java 11+ and is considered experimental for the time being. Finally, care must be taken to use the same exact JVM version when building and running the application.
When AppCDS generation is enabled, if this property is set, then the JVM used to generate the AppCDS file will be the JVM present in the container image. The builder image is expected to have the 'java' binary on its PATH. This flag is useful when the JVM to be used at runtime is not the same exact JVM version as the one used to build the jar. Note that this property is consulted only when quarkus.package.jar.appcds.enabled=true and it requires having docker available during the build.
Normally, if either a suitable container image to use to create the AppCDS archive can be determined automatically or if one is explicitly set using the quarkus..appcds.builder-image setting, the AppCDS archive is generated by running the JDK contained in the image as a container.
If this option is set to false, a container will not be used to generate the AppCDS archive. Instead, the JDK used to build the application is also used to create the archive. Note that the exact same JDK version must be used to run the application in this case.
If this is specified a directory of this name will be created in the jar distribution. Users can place jar files in this directory, and when re-augmentation is performed these will be processed and added to the class-path.
If this option is true then a list of all the coordinates of the artifacts that made up this image will be included in the quarkus-app directory. This list can be used by vulnerability scanners to determine if your application has any vulnerable dependencies. Only supported for the JarType#FAST_JAR fast JAR and JarType#MUTABLE_JAR mutable JAR output types.
If your application has main classes annotated with io.quarkus.runtime.annotations.QuarkusMain then this can also reference the name given in the annotation, to avoid the need to specify fully qualified names in the config.
Custom manifest attributes to be added to the main section of the MANIFEST.MF file. An example of the user defined property: quarkus.package.jar.manifest.attributes."Entry-key1"=Value1 quarkus.package.jar.manifest.attributes."Entry-key2"=Value2
Custom manifest sections to be added to the MANIFEST.MF file. An example of the user defined property: quarkus.package.jar.manifest.sections."Section-Name"."Entry-Key1"=Value1 quarkus.package.jar.manifest.sections."Section-Name"."Entry-Key2"=Value2
By default, Quarkus tests in JVM mode are run using the test configuration profile. If you are not familiar with Quarkusconfiguration profiles, everything you need to know is explained in theConfiguration Profiles Documentation.
It is however possible to use a custom configuration profile for your tests with the Maven Surefire and Maven Failsafeconfigurations shown below. This can be useful if you need for example to run some tests using a specific database which is notyour default testing database.
Quarkus bootstrap includes a Maven resolver implementation that is used to resolve application runtime and build time dependencies. The Quarkus Maven resolver is initialized from the same Maven command line that launched the build, test or dev mode. Typically, there is no need to add any extra configuration for it. However, there could be cases where an extra configuration option may be necessary to properly resolve application dependencies in test or dev modes, or IDEs.