quarkus-update

Original：🇺🇸 English

Translated

Use when working in a Quarkus project and the user wants to check if their build files are up-to-date, compare project structure against a reference, or upgrade their Quarkus version. Triggers on "check project", "update quarkus", "is my project up to date", "compare build", "quarkus upgrade".

3installs

Sourcequarkusio/quarkus-skills

Added on2026-06-05

NPX Install

npx skill4agent add quarkusio/quarkus-skills quarkus-update

SKILL.md Content

View Translation Comparison →

Quarkus Project Check

Check if a Quarkus project's build files are up-to-date by comparing against reference generated projects from code-with-quarkus-compare.

Step 1: Detect Build Tool and Version

Identify which build file exists in the project root:

File	Build Tool	Tag prefix
`pom.xml`	Maven	`maven-`
`build.gradle`	Gradle	`gradle-`
`build.gradle.kts`	Gradle Kotlin DSL	`gradle-kotlin-dsl-`

Extract the Quarkus version:

Maven (
pom.xml
): Look for the

<quarkus.platform.version>

property, or the version of

quarkus-bom

in

<dependencyManagement>

Gradle (
build.gradle
): Look for

quarkusPlatformVersion

in the

ext

block or

gradle.properties

Gradle KTS (
build.gradle.kts
): Look for
```
val quarkusPlatformVersion
```
or the BOM declaration

Construct the reference tag:

{tag_prefix}{version}

(e.g.,

maven-3.15.7

).

Step 2: Compare Build Files Against Reference

Fetch the reference build file:

https://raw.githubusercontent.com/quarkusio/code-with-quarkus-compare/{tag}/{build_file}

For example:

https://raw.githubusercontent.com/quarkusio/code-with-quarkus-compare/maven-3.32.4/pom.xml

Compare the user's build file against the reference, focusing on:

Plugin versions and configurations (compiler plugin, surefire, failsafe, quarkus-maven-plugin)
BOM setup (dependency management structure)
Build properties (Java version, encoding, surefire-plugin.version)
Wrapper scripts (presence of
```
.mvnw
```
/
```
gradlew
```
, wrapper version)

Ignore user-specific content (do not flag these as differences):

Custom dependencies not present in the reference
groupId, artifactId, project name, version
Custom profiles, modules, or build customizations
Application-specific configuration

Report each meaningful difference with an explanation of what the reference project has and why it matters.

If the reference tag does not exist in the repository (404), inform the user that no reference is available for their specific version and suggest checking the available tags.

Step 3: Check for Newer Quarkus Version

Fetch the list of tags for the user's build tool to find the latest available version:

https://github.com/quarkusio/code-with-quarkus-compare/tags

Or use git:

git ls-remote --tags https://github.com/quarkusio/code-with-quarkus-compare.git '{tag_prefix}*'

Compare the user's version against the latest tag. If the user is already on the latest version, report that and stop here.

Step 4: Upgrade Analysis (if outdated)

When a newer version is available, combine two sources of information:

4a: Run

quarkus update --dry-run

This requires the

quarkus

CLI to be installed. Run:

bash

quarkus update --dry-run

This produces (without modifying any files):

Console output: BOM update suggestions, extension sync status, matched migration recipes
target/rewrite/rewrite.patch
— the actual diff of changes the update would apply
target/rewrite/rewrite.yaml
— the full OpenRewrite recipe (version bumps + migration rules)
target/rewrite/rewrite.log
— detailed execution log

Read

target/rewrite/rewrite.patch

to understand what code-level changes the update covers.

If the

quarkus

CLI is not available, skip this step and note it in the report.

4b: Fetch generator diff

Get the structural diff between the user's current version and the latest version using the GitHub compare view:

https://github.com/quarkusio/code-with-quarkus-compare/compare/{current_tag}...{latest_tag}

For example:

https://github.com/quarkusio/code-with-quarkus-compare/compare/maven-3.15.7...maven-3.32.4

This reveals structural changes that

quarkus update

may not cover, such as:

New plugin configurations (e.g.,
```
<argLine>
```
additions)
Surefire/failsafe version bumps
Wrapper script updates
Dockerfile changes
New or removed boilerplate files

4c: Unified report

Present a combined report:

Current status: Build tool, current Quarkus version, latest available version
What
quarkus update
would handle: Summarize the patch (version bumps, dependency renames, config key migrations)
What
quarkus update
does NOT cover: Structural differences from the generator diff that are absent from the patch — these require manual attention
Recommended actions:
- Run
```
quarkus update --yes
```
  to apply the automated migrations
- Manually apply remaining structural changes identified from the generator diff
- Link to the full comparison:
```
https://github.com/quarkusio/code-with-quarkus-compare/compare/{current_tag}...{latest_tag}
```