GO — Healthy across the board

• Last commit today
• 25+ active contributors
• Distributed ownership (top contributor 21% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Quarkus is a cloud-native Java framework optimized for container-first deployment, delivering supersonic startup times and minimal memory footprint by shifting compilation and optimization to build time. It unifies imperative and reactive programming models while supporting both JVM and GraalVM native compilation, enabling Java applications to run efficiently in Kubernetes and serverless environments. Monorepo structure: core framework logic in extensions (640+ files), build-time processing via Maven plugins, runtime in quarkus-runtime artifacts. Test infrastructure segregates JVM tests (.github/matrix-jvm-tests.json), native compilation tests (.github/native-tests.json), and integration tests. Agent skills directory (.agents/skills/) documents extension development, classloading, configuration, and build-step patterns.

Java developers building microservices, serverless functions, and cloud-native applications who need fast startup times, low memory usage, and container-optimized deployments without sacrificing the Java ecosystem (JAX-RS, Hibernate ORM, Eclipse MicroProfile standards).

Highly mature and production-ready: 64MB+ Java codebase with extensive CI/CD workflows (.github/workflows/ci-actions-incremental.yml, codeql-analysis.yml), comprehensive test matrix (JVM, native, integration tests), supported JVM versions 17-25, and active commit history. The project has significant GitHub stars and professional backing from Red Hat.

Low risk: well-established project with structured governance, extensive testing infrastructure, and clear dependency management via Maven (quarkus-bom maintains precise version pins). Risk factors are minimal—no abandoned features visible, active CI/CD, and breaking changes are managed across major versions. Dependency count is substantial but well-maintained (bouncycastle, resteasy, opentelemetry, micrometer).

Active development with CI pipelines running incremental tests (ci-actions-incremental.yml), Develocity build scan integration, and matrix testing across JVM/native/integration scenarios. Recent focus visible in OpenTelemetry instrumentation (2.26.1-alpha), Quarkus HTTP 5.5.0, and Micrometer 1.16.5 integration.

Clone and build: git clone https://github.com/quarkusio/quarkus.git && cd quarkus && mvn clean install -DskipTests. For development with dev container: open in VS Code with devcontainer extension (see .devcontainer/devcontainer.json). Requires JDK 17+.

Daily commands: Maven-based: mvn quarkus:dev for hot-reload development mode. For native: mvn clean package -Dnative (requires GraalVM). Verify with mvn test (JVM) or matrix testing via CI workflows for full coverage.

• .agents/skills/creating-extensions/SKILL.md: Authoritative guide for the extension development model, the primary way contributors add features to Quarkus
• .github/workflows/ci-actions-incremental.yml: Main CI pipeline defining test matrix, build strategies, and validation gates for PRs
• .github/matrix-jvm-tests.json: Defines JVM test matrix spanning multiple JDK versions and configurations
• pom.xml: Root POM declaring dependency versions and build-time configuration (BOM pattern at quarkus-bom level)
• .agents/skills/coding-style/SKILL.md: Documents project code style, formatting, and review conventions for contributors
• .devcontainer/devcontainer.json: Reproducible development environment setup for consistent onboarding across contributors

For extensions: see .agents/skills/creating-extensions/SKILL.md. Core changes: modify extension modules in quarkus-* directories. Configuration: .agents/skills/working-with-config/SKILL.md. Build steps: .agents/skills/writing-build-steps/SKILL.md. Tests: .agents/skills/writing-tests/SKILL.md and verify in .github/matrix-jvm-tests.json patterns.

GraalVM native compilation requires Mandrel/GraalVM SDK (not standard JDK); build-time optimization means some reflection-based libraries need explicit registration via reflection-config.json. Classloading differs between JVM and native modes—see .agents/skills/classloading-and-runtime-dev/SKILL.md. Maven multi-module builds can be slow without -DskipTests or incremental flags. Extension tests must follow patterns in .github/matrix-jvm-tests.json to avoid CI matrix misses.

• Build-time Optimization — Quarkus shifts class loading, annotation scanning, and initialization from runtime to Maven build phase, enabling instant startup and minimal memory—core to the 'supersonic' claim
• GraalVM Native Image Compilation — Converts Java bytecode to native executables; Quarkus uses reflection-config.json and bytecode rewriting to preserve dynamic features without full classpath scanning
• Jandex Bytecode Scanning — Quarkus uses Jandex (3.5.3) at build time to index annotations and class metadata without loading classes, enabling efficient extension discovery and configuration
• Classloading and Runtime Dev Mode — Quarkus hot-reload dev mode manages two classloaders (base + augmented) to enable live code updates without restart; understanding this is critical for extension debugging
• Extension Model & BuildSteps — Quarkus extensibility relies on BuildStep processors that run at compile time to register beans, config properties, and native image metadata—core pattern for all extensions
• Reactive & Imperative Unification — Quarkus merges Eclipse Vert.x (reactive, non-blocking) and traditional servlet models under one programming model, allowing developers to mix async and sync without conflicting abstractions
• Container-First Deployment Patterns — Quarkus enforces 12-factor app principles and Kubernetes-native defaults (graceful shutdown, liveness/readiness probes, resource limits) from the framework layer, not application code

• helidon/helidon — Alternative cloud-native Java microservices framework with similar goals (fast startup, container-first) but lighter weight than Quarkus
• micronaut-projects/micronaut-core — Competing framework in the compile-time optimized Java space with similar build-time processing and GraalVM native support
• spring-projects/spring-boot — Industry-standard Java framework that inspired some Quarkus patterns; Spring Native bridge the gap but Quarkus optimizes this natively
• quarkusio/quarkus-quickstarts — Official example projects and templates demonstrating Quarkus extensions, REST APIs, databases, and cloud deployment patterns
• graalvm/graalvm-ce-builds — GraalVM releases required for native compilation; understanding GraalVM internals is essential for debugging native image issues

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive SKILL.md documentation for extension testing patterns

The .agents/skills directory contains SKILL.md files for building-and-testing, creating-extensions, and writing-tests, but there's no dedicated skill guide that bridges these topics. A new SKILL.md should document the specific testing patterns and best practices for Quarkus extensions, including deployment tests, integration tests, and native image compilation tests. This would be high-value for new contributors working on extension-related PRs.

• [ ] Create .agents/skills/testing-extensions/SKILL.md
• [ ] Document extension test structure by examining existing extension tests in quarkus-*/src/test
• [ ] Include examples of @QuarkusTest, @QuarkusIntegrationTest, and native build testing patterns
• [ ] Reference the existing writing-tests and creating-extensions SKILL.md files for cross-linking
• [ ] Add practical examples of deployment testing and configuration injection for extensions

Add GitHub Actions workflow for validating BOM dependency versions consistency

The quarkus-bom POM contains many dependency version properties (shown in snippet: bouncycastle, opentelemetry, resteasy, micrometer, etc.). There's no apparent CI workflow to validate that critical transitive dependencies don't have conflicting versions across the BOM and extension POMs. This prevents dependency hell issues before they merge.

• [ ] Create .github/workflows/validate-bom-consistency.yml
• [ ] Use maven-dependency-plugin to generate dependency trees for core modules and popular extensions
• [ ] Validate no critical transitive dependencies have conflicting versions
• [ ] Run on PRs that modify pom.xml files matching **/pom.xml
• [ ] Reference .github/mvn-settings.xml for Maven configuration

Document and enhance the .agents/skills/pull-requests/SKILL.md with Quarkus-specific PR guidelines

While pull-requests/SKILL.md exists, it likely lacks Quarkus-specific guidance on extension PR requirements. Looking at the repo structure, new contributors need clear guidance on: which modules to modify for different contribution types, how to write release notes in PR descriptions, how to verify documentation builds, and when to add entries to .github/native-tests.json or other test matrix files.

• [ ] Review current .agents/skills/pull-requests/SKILL.md content
• [ ] Add section: 'PR checklist for extension changes' referencing .agents/skills/creating-extensions/SKILL.md
• [ ] Document how to verify if a PR requires updates to .github/{native-tests.json, matrix-jvm-tests.json, integration-tests.json}
• [ ] Add section on release notes format and where to document breaking changes
• [ ] Include example: 'extension PRs should include tests in quarkus-{extension-name}/src/test/java'

• Review extension documentation: many .agents/skills/ files mention creating new extensions; audit core extensions for matching SKILL.md patterns and add missing examples in extensions/*/docs/
• Add missing test coverage: .github/native-tests.json lists native scenarios but some extensions lack corresponding native test suites; identify gaps and submit PR with @QuarkusTest + @TestProfile native tests
• Improve error messages: build-time optimization failures often lack clarity; grep for IOException/GraalVMException in core and enhance messages with actionable next steps

The Quarkus project demonstrates a reasonable security posture with a documented security policy and dependency management practices. However, critical issues include the use of alpha/pre-release versions (OpenTelemetry) in production BOMs, which significantly increases vulnerability risk. Version fragmentation in security-critical cryptographic libraries (BouncyCastle) and incomplete dependency documentation further reduce confidence. Recommendations focus on eliminating pre-release dependencies, consolidating versions, and improving automated dependency governance. The project would benefit from more rigorous version management policies and dependency auditing practices.

• High · OpenTelemetry Instrumentation Alpha Version in Production BOM — pom.xml - opentelemetry-instrumentation.version property. The BOM includes opentelemetry-instrumentation version 2.26.1-alpha, which is an alpha/pre-release version. Alpha versions are not production-ready and may contain unpatched security vulnerabilities, unstable APIs, and breaking changes. Using alpha versions in a BOM that likely ships to production users is a significant risk. Fix: Upgrade to the latest stable release of opentelemetry-instrumentation. Alpha versions should only be used for development/testing, not in production BOMs.
• High · OpenTelemetry Semantic Conventions Alpha Version — pom.xml - opentelemetry-semconv.version property. The BOM specifies opentelemetry-semconv version 1.40.0-alpha, another pre-release/alpha version. This inconsistency with stable releases increases the attack surface and maintenance burden. Fix: Replace with the latest stable release of opentelemetry-semconv. Remove all alpha/pre-release dependencies from production BOMs.
• Medium · BouncyCastle FIPS Version Mismatch — pom.xml - bouncycastle.version, bouncycastle.fips.version, bouncycastle.tls.fips.version properties. The BOM declares three different BouncyCastle versions: standard (1.84), FIPS (2.1.2), and TLS FIPS (2.1.23). This fragmentation could lead to inconsistent cryptographic behavior, dependency resolution conflicts, and potential security issues if incompatible versions are loaded in the same application. Fix: Review the necessity of multiple BouncyCastle versions. Consolidate to a single stable version where possible, or document why multiple versions are required with strong justification.
• Medium · Incomplete Dependency Documentation — pom.xml - micrometer.version property and comment. The micrometer.version property has a comment indicating it should 'keep in sync with hdrhistogram' but the comment is incomplete and the actual synchronization is not visible. This suggests potential version management gaps. Fix: Complete the documentation comment and implement automated checks to ensure version alignment between interdependent components.
• Low · Missing Version Constraints for Security-Critical Libraries — pom.xml - Overall dependency management. While most dependencies are versioned, there's no evidence of upper-bound version constraints or dependency lock files to prevent transitive dependency updates that could introduce vulnerabilities. Fix: Consider implementing Maven Enforcer Plugin rules and dependency locking to prevent unintended version updates. Use tools like 'mvn dependency:tree' regularly to audit transitive dependencies.
• Low · Security Policy Email Endpoint Not Clearly Publicized — SECURITY.md. While a security policy exists and directs users to 'security at quarkus.io', the SECURITY.md file is incomplete (truncated). This could leave some users unable to properly report security issues. Fix: Ensure SECURITY.md is complete and clearly visible in the repository root. Consider adding a security.txt file per RFC 9110 for automated security disclosure discovery.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/quarkusio/quarkus shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live quarkusio/quarkus repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/quarkusio/quarkus.

What it runs against: a local clone of quarkusio/quarkus — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in quarkusio/quarkus | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of quarkusio/quarkus. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/quarkusio/quarkus.git
#   cd quarkus
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of quarkusio/quarkus and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "quarkusio/quarkus(\\.git)?\\b" \\
  && ok "origin remote is quarkusio/quarkus" \\
  || miss "origin remote is not quarkusio/quarkus (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/quarkusio/quarkus"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.