Build Tooling and Language Support

This section documents Quarkus 3.39.x (current) with 3.33.x LTS as the production recommendation, on the Java 17+ baseline, as published at the official Quarkus guides — which are the reference these pages are written and verified against.

Quarkus 4 raises the baseline to Java 21 (first release candidate planned for end of September 2026, see the Quarkus blog); readers upgrading past 3.39.x/3.33.x LTS should expect that change.

This content was generated with the assistance of AI and should be verified against those official guides before being relied on in production.

This section’s bibliography lists the reference material consulted while preparing these pages.

Getting a first project running with the CLI, Maven, or Gradle is covered on Getting Started with Quarkus; this page goes one level deeper into each tool’s day-to-day command surface, how a project moves between Quarkus versions with quarkus update, IDE support, build analytics, and the tooling/build-config mechanics of adding Kotlin to a project — deliberately leaving the language-choice discussion (null safety, coroutines vs. Mutiny, boilerplate) to Java or Kotlin for Quarkus? rather than repeating it here.

The Quarkus CLI

Beyond quarkus create (covered in Getting Started), the CLI’s other subcommands cover the rest of the everyday inner loop and a project’s lifecycle end to end:

quarkus extension add hibernate-orm-panache rest-jackson   # add extensions to the current project
quarkus extension list                                      # list installed and available extensions
quarkus dev                                                  # start dev mode (live reload, Dev UI, continuous testing)
quarkus build                                                # package the application (JAR by default)
quarkus build --native                                       # package as a native executable
quarkus image build                                          # build a container image from the packaged app
quarkus image push                                           # push that image to a registry
quarkus deploy kubernetes                                    # generate and apply Kubernetes manifests
quarkus deploy openshift                                     # equivalent for OpenShift
quarkus update                                                # migrate the project to a newer Quarkus version

quarkus image and quarkus deploy delegate to whichever container-image and Kubernetes/OpenShift extensions the project has installed (covered on Container Images and Kubernetes and OpenShift) rather than implementing image building or cluster deployment themselves — the CLI subcommand is a thin, consistent front end over whatever those extensions generate.

Maven

The quarkus-maven-plugin, added by every Maven-based project the CLI or code.quarkus.io generates, exposes the same lifecycle as goals rather than CLI subcommands:

./mvnw quarkus:dev                    # dev mode -- equivalent to `quarkus dev`
./mvnw quarkus:build                  # equivalent to `quarkus build`
./mvnw quarkus:add-extension -Dextensions="rest-jackson"
./mvnw quarkus:list-extensions
./mvnw quarkus:image-build
./mvnw quarkus:deploy -Dquarkus.kubernetes.deploy=true
./mvnw quarkus:update

./mvnw quarkus:dev and the CLI’s quarkus dev are functionally equivalent — both start the same dev-mode process described on Developer Experience — the choice between them is purely about whether Maven or the CLI is already the project’s primary entry point. The quarkus-bom import that pins every extension’s version (covered on Extensions and the Platform) lives in the same pom.xml this plugin operates on.

A generated project’s native build is normally wired behind a Maven profile rather than a bare property, so that CI or a developer opts in explicitly:

<profiles>
    <profile>
        <id>native</id>
        <activation>
            <property>
                <name>native</name>
            </property>
        </activation>
        <properties>
            <quarkus.native.enabled>true</quarkus.native.enabled>
        </properties>
    </profile>
</profiles>
./mvnw package -Pnative

Gradle

The Quarkus Gradle plugin (io.quarkus) mirrors the same lifecycle as Gradle tasks:

// build.gradle.kts
plugins {
    id("io.quarkus") version "3.39.0"
}
./gradlew quarkusDev                  # dev mode
./gradlew build                       # package the application
./gradlew build -Dquarkus.native.enabled=true    # package as a native executable
./gradlew quarkusAddExtension --extensions="rest-jackson"
./gradlew quarkusListExtensions
./gradlew quarkusUpdate

The most notable differences from Maven are conventions rather than missing features: Gradle resolves extensions through the ordinary implementation/testImplementation dependency configurations instead of a plugin-specific goal parameter, native-image activation is a Quarkus configuration property passed at the Gradle command line (-Dquarkus.native.enabled=true) rather than a dedicated Maven profile, and a multi-module Gradle build applies the io.quarkus plugin only to the module that actually produces the runnable application, not to every module in the build. See the Gradle Tooling guide for the authoritative, exact task and configuration names, since these evolve slightly across Quarkus releases.

Updating across Quarkus versions: quarkus update

quarkus update (CLI) and ./mvnw quarkus:update / ./gradlew quarkusUpdate (build-tool equivalents) migrate a project to a newer Quarkus version using recipe-based source transformations powered by OpenRewrite — covered in more detail, including why an extension needs no manual version pinning for this to work safely, on Extensions and the Platform. Each Quarkus release ships a matching set of update recipes that apply the mechanical changes a version bump typically requires — renamed artifacts, moved packages, updated configuration property keys — so most of a version upgrade is applied automatically rather than discovered one compiler error at a time.

IDE support

the IDE Tooling guide documents first-party plugins for the major Java IDEs — IntelliJ IDEA, Visual Studio Code (the Quarkus extension pack), and Eclipse/Red Hat CodeReady Studio. Each integrates with the same dev-mode process described on Developer Experience: live-reload triggers from within the IDE, application.properties/application.yaml key completion and validation sourced from installed extensions' actual configuration metadata, and a shortcut into the running Dev UI (/q/dev) without leaving the editor.

Build analytics and opting out

The Quarkus CLI collects anonymous build analytics by default — which commands are run and which extensions are added, with no project-identifying or source-code content — to help the Quarkus team prioritize tooling work. It can be disabled per-project or globally:

quarkus config set quarkus.analytics.disabled true

or via an environment variable, useful for CI where no persistent CLI config should be written:

export QUARKUS_ANALYTICS_DISABLED=true

Consult the CLI Tooling guide for the current, authoritative opt-out mechanism and exactly what is and is not collected.

Language support: Kotlin

Adding Kotlin support to a project is a single extension:

./mvnw quarkus:add-extension -Dextensions=kotlin

which wires the Kotlin standard library and compiler into the Maven/Gradle build. Two Kotlin compiler plugins — all-open and no-arg — are needed alongside it for CDI proxies and Panache active-record entities to work under Kotlin’s final-by-default classes; the exact Maven and Gradle configuration for both, and why Quarkus needs them (tied to ArC’s build-time CDI proxying and Panache’s Hibernate-backed entities), are covered in full on Java or Kotlin for Quarkus? rather than repeated here — this page stays to the tooling/build-config mechanics.

Panache Kotlin variants

Panache’s Java API (Panache) relies on public fields and static methods inherited from a Java superclass — both awkward fits for idiomatic Kotlin, which favors properties over public fields and has no direct equivalent of Java’s inherited static methods. The hibernate-orm-panache-kotlin extension provides a Kotlin-idiomatic API covering the same ground:

./mvnw quarkus:add-extension -Dextensions=hibernate-orm-panache-kotlin,jdbc-postgresql
package com.example.book

import io.quarkus.hibernate.orm.panache.kotlin.PanacheEntity
import io.quarkus.hibernate.orm.panache.kotlin.PanacheCompanion
import jakarta.persistence.Entity

@Entity
class Book : PanacheEntity() {

    lateinit var title: String
    lateinit var author: String

    companion object : PanacheCompanion<Book>
}

Persistent state is declared as ordinary Kotlin var properties instead of Java’s public fields, and the Panache "static" methods (findAll(), list(…​), persist(…​)) are supplied by having the entity’s companion object implement PanacheCompanion<Book> — Kotlin’s closest equivalent to Java’s inherited static methods — so Book.findAll() and Book.list("title", title) read identically to the Java active-record form. A repository-style equivalent, PanacheRepository<Book> from the same kotlin package, mirrors the Java repository pattern with no entity superclass required, the same choice between styles documented on the Panache page.

Scala and Groovy

Neither Scala nor Groovy has a dedicated Quarkus extension or first-class support commitment comparable to Kotlin’s — both can run on Quarkus as ordinary JVM languages compiled into the same classpath, but without the all-open/no-arg-equivalent tooling or the CLI/IDE integration Kotlin gets, so most Quarkus applications choosing a JVM language beyond Java pick Kotlin specifically because of that first-class support.

References