Quarkus - Building applications with Maven

    The following table lists the attributes you can pass to the create command:

    AttributeDefault ValueDescription
    projectGroupIdorg.acme.sampleThe group id of the created project
    projectArtifactIdmandatoryThe artifact id of the created project. Not passing it triggers the interactive mode.
    projectVersion1.0-SNAPSHOTThe version of the created project
    classNameNot created if omittedThe fully qualified name of the generated resource
    path/helloThe resource path, only relevant if className is set.
    extensions[]The list of extensions to add to the project (comma-separated)

    If you decide to generate a REST resource (using the className attribute), the endpoint is exposed at: http://localhost:8080/$path.If you use the default path, the URL is: .

    The project is generated in a directory named after the passed artifactId.If the directory already exists, the generation fails.

    A pair of Dockerfiles for native and jvm mode are also generated in src/main/docker.Instructions to build the image and run the container are written in those Dockerfiles.

    Dealing with extensions

    From inside a Quarkus project, you can obtain a list of the available extensions with:

    1. ./mvnw quarkus:list-extensions

    You can enable an extension using:

    1. ./mvnw quarkus:add-extension -Dextensions="hibernate-validator"

    Extensions are passed using a comma-separated list.

    The extension name is the GAV name of the extension: e.g. io.quarkus:quarkus-agroal.But you can pass a partial name and Quarkus will do its best to find the right extension.For example, agroal, Agroal or agro will expand to io.quarkus:quarkus-agroal.If no extension is found or if more than one extensions match, you will see a red check mark ❌ in the command result.

    1. $ ./mvnw quarkus:add-extensions -Dextensions=jdbc,agroal,non-exist-ent
    2. [...]
    3. Multiple extensions matching 'jdbc'
    4. * io.quarkus:quarkus-jdbc-h2
    5. * io.quarkus:quarkus-jdbc-mariadb
    6. * io.quarkus:quarkus-jdbc-postgresql
    7. Be more specific e.g using the exact name or the full gav.
    8. Adding extension io.quarkus:quarkus-agroal
    9. Cannot find a dependency matching 'non-exist-ent', maybe a typo?
    10. [...]

    You can install all extensions which match a globbing pattern :

    1. ./mvnw quarkus:add-extension -Dextensions="hibernate-*"

    Development mode

    Quarkus comes with a built-in development mode.Run your application with:

    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.

    quarkus:dev 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.

    Hit CTRL+C to stop the application.

    It is possible to use development mode remotely, so that you can run Quarkus in a container environment (such as Openshift)and have changes made to your local files become immediately visible.

    This allows you to develop in the same environment you will actually run your app in, and with access to the same services.

    To do this you must have the quarkus-undertow-websockets extension installed:

    1. ./mvnw quarkus:add-extension -Dextensions="undertow-websockets"

    You must also have the following config properties set:

    • quarkus.live-reload.password

    • quarkus.live-reload.url

    These can be set via application.properties, or any other way (e.g. system properties, environment vars etc). Thepassword must be set on both the local and remote processes, while the url only needs to be set on the local host.

    Start Quarkus in dev mode on the remote host. Now you need to connect your local agent to the remote host:

    1. ./mvnw quarkus:remote-dev -Dquarkus.live-reload.url=http://my-remote-host:8080

    Now every time you refresh the browser you should see any changes you have made locally immediately visible in the remoteapp.

    By default, the Maven plugin picks up compiler flags to pass tojavac from maven-compiler-plugin.

    If you need to customize the compiler flags used in development mode,add a configuration section to the plugin block and set thecompilerArgs property just as you would when configuringmaven-compiler-plugin. You can also set source, target, andjvmArgs. For example, to pass —enable-preview to both the JVMand javac:

    1. <plugin>
    2. <groupId>io.quarkus</groupId>
    3. <artifactId>quarkus-maven-plugin</artifactId>
    4. <version>${quarkus.version}</version>
    5. <configuration>
    6. <source>${maven.compiler.source}</source>
    7. <target>${maven.compiler.target}</target>
    8. <compilerArgs>
    9. <arg>--enable-preview</arg>
    10. </compilerArgs>
    11. <jvmArgs>--enable-preview</jvmArgs>
    12. </configuration>
    13. ...
    14. </plugin>

    This behavior can be changed by giving the debug system property one of the following values:

    • false - the JVM will start with debug mode disabled

    • true - The JVM is started in debug mode and will be listening on port 5005

    • client - the JVM will start in client mode and attempt to connect to localhost:5005

    • {port} - The JVM is started in debug mode and will be listening on {port}

    An additional system property suspend can be used to suspend the JVM, when launched in debug mode. suspend supports the following values:

    • y or true - The debug mode JVM launch is suspended

    • n or false - The debug mode JVM is started without suspending

    You can also run a Quarkus application in debug mode with a suspended JVM using ./mvnw compile quarkus:dev -Ddebug which is a shorthand for .Then, attach your debugger to localhost:5005.

    Import in your IDE

    Once you have a , you can import it in your favorite IDE.The only requirement is the ability to import a Maven project.

    Eclipse

    In Eclipse, click on: File → Import.In the wizard, select: Maven → Existing Maven Project.On the next screen, select the root location of the project.The next screen list the found modules; select the generated project and click on Finish. Done!

    In a separated terminal, run ./mvnw compile quarkus:dev, and enjoy a highly productive environment.

    IntelliJ

    In IntelliJ:

    • From inside IntelliJ select File → New → Project From Existing Sources…​ or, if you are on the welcome dialog, select Import project.

    • Select the project root

    • Select Import project from external model and Maven

    • Next a few times (review the different options if needed)

    • On the last screen click on Finish

    In a separated terminal or in the embedded terminal, run ./mvnw compile quarkus:dev. Enjoy!

    Apache Netbeans

    In Netbeans:

    • Select File → Open Project

    • Select the project root

    In a separated terminal or the embedded terminal, go to the project root and run ./mvnw compile quarkus:dev. Enjoy!

    Visual Studio Code

    Open the project directory in VS Code. If you have installed the Java Extension Pack (grouping a set of Java extensions), the project is loaded as a Maven project.

    Logging Quarkus application build classpath tree

    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-bootstrap Maven plugin includes the build-tree goal which displays the build dependency tree for the application.

    To be able to use it, the following plugin configuration has to be added to the pom.xml:

    1. <groupId>io.quarkus</groupId>
    2. <artifactId>quarkus-bootstrap-maven-plugin</artifactId>
    3. <version>${quarkus.version}</version>
    4. </plugin>

    Now you should be able to execute ./mvnw quarkus-bootstrap:build-tree on your project and see something like:

    Native executables make Quarkus applications ideal for containers and serverless workloads.

    Make sure to have GRAALVM_HOME configured and pointing to GraalVM version 19.2.1.Verify that your pom.xml has the proper native profile (see ).

    Create a native executable using: ./mvnw package -Pnative.A native executable will be present in target/.

    To run Integration Tests on the native executable, make sure to have the proper Maven plugin configured (see Maven configuration) and launch the verify goal.

    1. ./mvnw verify -Pnative
    2. ...
    3. [quarkus-quickstart-runner:50955] universe: 391.96 ms
    4. [quarkus-quickstart-runner:50955] (parse): 904.37 ms
    5. [quarkus-quickstart-runner:50955] (inline): 1,143.32 ms
    6. [quarkus-quickstart-runner:50955] (compile): 6,228.44 ms
    7. [quarkus-quickstart-runner:50955] compile: 9,130.58 ms
    8. [quarkus-quickstart-runner:50955] image: 2,101.42 ms
    9. [quarkus-quickstart-runner:50955] write: 803.18 ms
    10. [quarkus-quickstart-runner:50955] [total]: 33,520.15 ms
    11. [INFO]
    12. [INFO] --- maven-failsafe-plugin:2.22.0:integration-test (default) @ quarkus-quickstart-native ---
    13. [INFO]
    14. [INFO] -------------------------------------------------------
    15. [INFO] T E S T S
    16. [INFO] -------------------------------------------------------
    17. [INFO] Running org.acme.quickstart.GreetingResourceIT
    18. Executing [/Users/starksm/Dev/JBoss/Quarkus/starksm64-quarkus-quickstarts/getting-started-native/target/quarkus-quickstart-runner, -Dquarkus.http.port=8081, -Dtest.url=http://localhost:8081, -Dquarkus.log.file.path=target/quarkus.log]
    19. 2019-02-28 16:52:42,020 INFO [io.quarkus] (main) Quarkus started in 0.007s. Listening on: http://localhost:8080
    20. 2019-02-28 16:52:42,021 INFO [io.quarkus] (main) Installed features: [cdi, resteasy]
    21. [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.081 s - in org.acme.quickstart.GreetingResourceIT
    22. [INFO]
    23. [INFO] Results:
    24. [INFO]
    25. [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
    26. ...

    The native executable will be specific to your operating system.To create an executable that will run in a container, use the following:

    1. ./mvnw package -Dnative -Dquarkus.native.container-build=true

    The produced executable will be a 64 bit Linux executable, so depending on your operating system it may no longer be runnable.However, it’s not an issue as we are going to copy it to a Docker container.Note that in this case the build itself runs in a Docker container too, so you don’t need to have GraalVM installed locally.

    You can follow the as well as Deploying Application to Kubernetes and OpenShift for more information.

    Maven configuration

    If you have not used project scaffolding, add the following elements in your pom.xml

    1. <dependencyManagement>
    2. <dependencies>
    3. <dependency> (1)
    4. <groupId>io.quarkus</groupId>
    5. <artifactId>quarkus-bom</artifactId>
    6. <version>${quarkus.version}</version>
    7. <type>pom</type>
    8. <scope>import</scope>
    9. </dependency>
    10. </dependencies>
    11. </dependencyManagement>
    12. <build>
    13. <plugins>
    14. <plugin> (2)
    15. <groupId>io.quarkus</groupId>
    16. <artifactId>quarkus-maven-plugin</artifactId>
    17. <version>${quarkus.version}</version>
    18. <executions>
    19. <execution>
    20. <goals>
    21. <goal>build</goal>
    22. </goals>
    23. </execution>
    24. </executions>
    25. </plugin>
    26. </plugins>
    27. <profile> (3)
    28. <id>native</id>
    29. <properties> (4)
    30. <quarkus.package.type>native</quarkus.package.type>
    31. </properties>
    32. <build>
    33. <plugins>
    34. <plugin> (5)
    35. <groupId>org.apache.maven.plugins</groupId>
    36. <artifactId>maven-failsafe-plugin</artifactId>
    37. <version>${surefire-plugin.version}</version>
    38. <executions>
    39. <execution>
    40. <goals>
    41. <goal>integration-test</goal>
    42. <goal>verify</goal>
    43. </goals>
    44. <configuration>
    45. <systemProperties>
    46. <native.image.path>${project.build.directory}/${project.build.finalName}-runner</native.image.path>
    47. </systemProperties>
    48. </configuration>
    49. </execution>
    50. </executions>
    51. </plugin>
    52. </plugins>
    53. </build>
    54. </profile>
    55. </profiles>

    Quarkus Maven plugin supports the generation of Uber-Jars by specifying a quarkus.package.uber-jar=true configuration option in your application.properties.

    The original jar will still be present in the target directory but it will be renamed to contain the .original suffix.

    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 seperated list of entries to ignore.

    Uber-Jar creation by default excludes that might be present in the dependencies of the application.

    Uber-Jar’s final name is configurable via a Maven’s build settings finalName option.

    Configuring the Project Output

    There are a several configuration options that will define what the output of your project build will be.These are provided in application.properties the same as any other config property.

    The properties are shown below:

    Configuration property fixed at build time - ️ Configuration property overridable at runtime

    Configuration propertyTypeDefault
    quarkus.package.typeThe requested output type. The default built in types are jar and nativestringjar
    quarkus.package.uber-jarIf the java runner should be packed as an uberjarbooleanfalse
    quarkus.package.main-classThe entry point of the application. In most cases this should not be modified.stringio.quarkus.runner.GeneratedMain
    quarkus.package.user-configured-ignored-entriesFiles that should not be copied to the output artifactlist of stringrequired
    quarkus.package.runner-suffixThe suffix that is applied to the runner jar and native imagesstring-runner

    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 the.

    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.

    1. <project>
    2. [...]
    3. <build>
    4. <plugins>
    5. <plugin>
    6. <groupId>org.apache.maven.plugins</groupId>
    7. <artifactId>maven-surefire-plugin</artifactId>
    8. <version>${surefire-plugin.version}</version>
    9. <configuration>
    10. <systemPropertyVariables>
    11. <quarkus.test.profile>foo</quarkus.test.profile> (1)
    12. <buildDirectory>${project.build.directory}</buildDirectory>
    13. [...]
    14. </systemPropertyVariables>
    15. </configuration>
    16. </plugin>
    17. <plugin>
    18. <groupId>org.apache.maven.plugins</groupId>
    19. <artifactId>maven-failsafe-plugin</artifactId>
    20. <version>${failsafe-plugin.version}</version>
    21. <configuration>
    22. <systemPropertyVariables>
    23. <quarkus.test.profile>foo</quarkus.test.profile> (1)
    24. <buildDirectory>${project.build.directory}</buildDirectory>
    25. [...]
    26. </systemPropertyVariables>
    27. </configuration>
    28. </plugin>
    29. </plugins>
    30. </build>
    31. [...]
    32. </project>
    It is not possible to use a custom test configuration profile in native mode for now. Native tests are always run using the profile.