How does Atlas handle Quarkus build-time augmentation during refactoring?

Atlas is designed to work within Quarkus's build-time augmentation constraints. It can be asked to replace runtime reflection with build-time-friendly patterns, ensuring that refactored classes survive native-image compilation and maintain optimal performance.

Can Atlas help refactor application.properties configurations in Quarkus?

Yes, Atlas can read your `application.properties` and understand its context. When refactoring, it can propose changes to property keys or values, ensuring consistency with your updated code, and will present a diff for approval.

How does Atlas ensure my Quarkus tests are not broken by refactoring?

Atlas pins behavior by running your `JUnit 5 (@QuarkusTest)` suite with `./mvnw test` to establish a green baseline. It then re-runs these tests after every incremental change, immediately flagging any failures to prevent regressions.

What if Atlas proposes a change that I do not agree with in my Quarkus project?

Atlas operates with explicit developer approval. It drafts a plan in a read-only agent, computes a unified diff for every file edit, and requires your approval before writing any changes. You can review, modify, or reject any proposed change.

Does Atlas support Maven for Quarkus project refactoring?

Absolutely. Atlas runs in projects with a `pom.xml` that pulls in `quarkus-bom`. It uses `Maven` commands like `./mvnw test` via its `bash` tool for building, testing, and managing dependencies within your Quarkus project.

How does Atlas ensure code style consistency with Spotless in Quarkus?

After applying refactoring changes, Atlas can be instructed to apply `Spotless` formatting to your Quarkus codebase. This ensures that all modified files adhere to your project's defined code style rules before they are committed, maintaining consistency.

Can Atlas help me add new @QuarkusTest cases during a refactor?

Yes, Atlas can add new `@QuarkusTest` cases, potentially using `RestAssured` for integration tests, to cover new or modified functionality. It will run these new tests via `./mvnw test` behind a permission prompt, ensuring they pass.

Refactor a legacy module in Quarkus with Atlas in 2026

Refactoring a legacy Quarkus module without altering its behavior or breaking callers is a precise task that Atlas simplifies by leveraging your existing Maven and JUnit 5 (@QuarkusTest) toolchain. Atlas maps the module's public surface, pins current behavior with tests, and applies structural changes incrementally, ensuring every modification is validated against your application.properties and pom.xml configurations before committing.

How does Atlas map Quarkus module dependencies for refactoring?

In 2026, understanding a legacy Quarkus module's public surface and its callers is the first critical step in any refactor. Atlas uses the lsp tool's documentSymbol operation to map all exported symbols, including CDI beans and JAX-RS resources, providing a comprehensive view.

Atlas initiates the refactoring process by building a detailed map of the Quarkus module's public API. It leverages its lsp tool, which interacts with the language server, to perform a documentSymbol operation. This operation identifies all top-level declarations within the module, such as CDI beans annotated for injection, JAX-RS resources exposing REST endpoints, and other public classes or methods. Once the public surface is mapped, Atlas then executes findReferences on each identified symbol. This crucial step enumerates every single callsite across the entire codebase, ensuring that no external dependency on the module goes unnoticed. This comprehensive mapping, built on AST declarations using tree-sitter, prevents silent breakage by providing a complete picture of the module's interaction points before any code is modified. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers.

How does Atlas ensure Quarkus module behavior remains unchanged during refactoring?

Pinning the existing behavior of a Quarkus module is paramount to a safe refactor, preventing regressions. Atlas achieves this by running your JUnit 5 (@QuarkusTest) suite via the bash tool, recording a green baseline of 100% passing tests before any code changes are introduced.

Before Atlas proposes any structural changes, it establishes a robust safety net by pinning the module's current behavior. This involves using the bash tool to execute the existing test suite. For Quarkus projects, this means running `./mvnw test`, which triggers all JUnit 5 (@QuarkusTest) cases. Atlas records the output, ensuring that all tests pass and establishing a "green baseline." This baseline serves as the definitive proof of the module's intended functionality. Every subsequent change made during the refactoring process will be immediately validated against this baseline. If any test fails after a modification, Atlas flags it, indicating a potential behavioral change or regression, allowing developers to address it before proceeding. This iterative testing approach, running tests after each hunk lands, is a core safety mechanism.

How does Atlas apply structural changes to Quarkus code safely?

Applying structural changes to a Quarkus module requires precision to avoid introducing errors or breaking the build. Atlas uses its apply_patch tool, which anchors on context lines and old lines, refusing to apply a patch if the file has drifted, ensuring a 0-risk application process.

When it is time to restructure the Quarkus module, Atlas employs its apply_patch tool. This tool is designed for robust and safe code modification. Instead of blindly overwriting files, apply_patch seeks out each hunk's context and old_lines within the target file. This means that for a patch to apply successfully, the surrounding code must exactly match the context provided in the patch. If the file has drifted,meaning the context lines or old lines no longer match,apply_patch will fail with a "Failed to find context" error. This mechanism prevents applying changes to an outdated or unexpectedly modified file, significantly reducing the risk of introducing subtle bugs or merge conflicts. Atlas also computes a unified diff for every file edit and surfaces it for approval before writing, giving the developer full control. This process is crucial for maintaining the integrity of pom.xml and application.properties during refactoring.

How does Atlas manage refactoring progress and ensure continuous validation in Quarkus?

Managing the progress of a Quarkus module refactor and ensuring continuous validation is crucial for large-scale changes. Atlas re-runs JUnit 5 (@QuarkusTest) cases with bash after each patch hunk lands, and tracks remaining work with a todowrite list, preventing incomplete migrations.

Atlas adopts an iterative and continuously validated approach to refactoring. After each individual hunk of a patch is successfully applied by apply_patch, Atlas immediately re-runs the JUnit 5 (@QuarkusTest) suite using the bash tool (./mvnw test). This ensures that any behavioral regressions are caught as soon as they are introduced, rather than discovering a cascade of failures at the very end of a large refactor. Furthermore, Atlas uses the todowrite tool to maintain a list of remaining callsites that still need migration. This list, generated from the initial findReferences step, ensures that a partially migrated module cannot be mistaken for a finished one. Developers can track progress and ensure every callsite is updated, preventing silent breakage and ensuring the module's public contract remains consistent. Atlas also reads git branches, status, and diffs, and can stage and create commits on your behalf, streamlining the workflow.

What safety and review mechanisms does Atlas provide for Quarkus refactoring?

Atlas integrates multiple safety and review mechanisms to ensure Quarkus refactoring is secure and transparent. Every Atlas tool call is permission-gated, and a read-only plan agent drafts changes before a build agent executes them, providing 2-step approval.

Atlas prioritizes safety and developer oversight throughout the refactoring process. Every tool call, whether it is lsp, bash, or apply_patch, is permission-gated against allow, ask, and deny rules, giving developers granular control over what Atlas can execute. Before any changes are made, Atlas drafts a comprehensive plan in a read-only plan agent, which is then presented for developer approval. Only after approval does Atlas switch to a build agent to execute the plan. For every file edit, Atlas computes a unified diff and surfaces it for approval before writing, allowing developers to review exact changes. After applying changes, Atlas can add @QuarkusTest cases with RestAssured and run ./mvnw test behind a permission prompt. Finally, Atlas can apply Spotless formatting before committing, ensuring code style consistency. Atlas snapshots file changes as git patches, allowing edits to be diffed and rolled back easily.

Step by step

01Map the Quarkus module's public surface: Run `atlas lsp documentSymbol` to identify all CDI beans, JAX-RS resources, and other public declarations within your `pom.xml` project.
02Enumerate all callers: For each identified symbol, execute `atlas lsp findReferences` to list every callsite across your Quarkus codebase, tracking them with `atlas todowrite`.
03Pin existing behavior: Use `atlas bash` to run your `JUnit 5 (@QuarkusTest)` suite with `./mvnw test` and record the green baseline of passing tests.
04Apply structural changes incrementally: Use `atlas apply_patch` to introduce refactoring changes, ensuring each hunk anchors on context lines and `old_lines` to prevent drift.
05Validate after each change: After each `apply_patch` hunk, re-run `atlas bash ./mvnw test` to immediately verify that `JUnit 5 (@QuarkusTest)` cases still pass.
06Review and format: Review the unified diff provided by Atlas, then let Atlas apply `Spotless` formatting before staging and committing changes with its git integration.

Frequently asked questions

How does Atlas handle Quarkus build-time augmentation during refactoring?: Atlas is designed to work within Quarkus's build-time augmentation constraints. It can be asked to replace runtime reflection with build-time-friendly patterns, ensuring that refactored classes survive native-image compilation and maintain optimal performance.
Can Atlas help refactor application.properties configurations in Quarkus?: Yes, Atlas can read your `application.properties` and understand its context. When refactoring, it can propose changes to property keys or values, ensuring consistency with your updated code, and will present a diff for approval.
How does Atlas ensure my Quarkus tests are not broken by refactoring?: Atlas pins behavior by running your `JUnit 5 (@QuarkusTest)` suite with `./mvnw test` to establish a green baseline. It then re-runs these tests after every incremental change, immediately flagging any failures to prevent regressions.
What if Atlas proposes a change that I do not agree with in my Quarkus project?: Atlas operates with explicit developer approval. It drafts a plan in a read-only agent, computes a unified diff for every file edit, and requires your approval before writing any changes. You can review, modify, or reject any proposed change.
Does Atlas support Maven for Quarkus project refactoring?: Absolutely. Atlas runs in projects with a `pom.xml` that pulls in `quarkus-bom`. It uses `Maven` commands like `./mvnw test` via its `bash` tool for building, testing, and managing dependencies within your Quarkus project.
How does Atlas ensure code style consistency with Spotless in Quarkus?: After applying refactoring changes, Atlas can be instructed to apply `Spotless` formatting to your Quarkus codebase. This ensures that all modified files adhere to your project's defined code style rules before they are committed, maintaining consistency.
Can Atlas help me add new @QuarkusTest cases during a refactor?: Yes, Atlas can add new `@QuarkusTest` cases, potentially using `RestAssured` for integration tests, to cover new or modified functionality. It will run these new tests via `./mvnw test` behind a permission prompt, ensuring they pass.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Refactor a Legacy Module with Atlas in 2026

How to refactor a legacy module with Atlas in 2026: findReferences maps every callsite, apply_patch refuses to apply against a drifted file, and bash proves behavior.

Atlas for Quarkus in 2026

Atlas is a terminal-native AI coding agent for Quarkus in 2026. It reads CDI beans and JAX-RS resources, then runs ./mvnw test behind a permission prompt.

Audit a Quarkus Repo with Parallel Subagents in Atlas in 2026

Sweep your Quarkus repository for problems without blowing your context window. Atlas uses parallel subagents, JUnit 5, Maven, and Spotless for efficient, safe audits.

Run the test suite and triage the failures in Quarkus with Atlas in 2026

In 2026, Quarkus developers use Atlas to efficiently run JUnit 5 (@QuarkusTest) suites, parse extensive failure logs, and prioritize distinct root causes for rapid resolution.

Onboard to an Unfamiliar Quarkus Codebase with Atlas in 2026

Quickly build a working mental model of any Quarkus codebase in 2026 with Atlas. Leverage semantic search, AST indexing, and direct interaction with Maven, JUnit 5 (@QuarkusTest), and Spotless to understand unfamiliar

Diagnose a hanging or long-running command in Quarkus with Atlas in 2026

In 2026, Quarkus developers use Atlas to diagnose hanging or slow Maven builds and scripts. Quickly identify if a command is blocked on input or genuinely slow, and get unstuck.

Trace a runtime bug from a stack trace in Quarkus with Atlas in 2026

Pinpoint and fix Quarkus runtime bugs from production stack traces using Atlas, the terminal-native AI agent. Leverage Maven, JUnit 5, and Spotless for rapid resolution.

Extract a Shared Helper from Duplicated Quarkus Code with Atlas in 2026

Streamline your Quarkus applications in 2026 by extracting duplicated logic into shared, tested helpers using Atlas. Find semantic duplicates, refactor with confidence, and ensure code quality with Maven and JUnit 5.

Browse this resource hub