How does Atlas handle `pom.xml` changes in Quarkus projects?

Atlas reads your `pom.xml` to understand project dependencies and build configurations, allowing it to execute `Maven` commands like `./mvnw test` and `spotless:apply` directly. Any proposed modifications to the `pom.xml` itself will be presented as a unified diff for your explicit approval before Atlas writes them.

Can Atlas run `JUnit 5 (@QuarkusTest)` tests for my Quarkus application?

Yes, Atlas can run `JUnit 5 (@QuarkusTest)` tests by invoking `./mvnw test` through its `bash` tool, surfacing the results directly in your terminal. It can also assist in adding new `@QuarkusTest` cases with `RestAssured` behind a permission prompt, ensuring comprehensive test coverage.

How does Atlas ensure code style with `Spotless` in Quarkus development?

Atlas integrates with `Spotless` by executing `./mvnw spotless:apply` before committing, ensuring your Quarkus codebase adheres to defined formatting standards. This step is permission-gated, giving you control, and helps maintain consistent code style across your project.

What Quarkus-specific files and idioms does Atlas understand?

Atlas understands Quarkus-specific files such as `pom.xml`, `application.properties`, `CDI beans`, and `JAX-RS resources`. It indexes code by AST declarations using tree-sitter, not blind line windows, allowing for precise understanding of Quarkus idioms and structures.

How does Atlas help with native-image compatibility in Quarkus?

Atlas can assist in replacing runtime reflection with build-time-friendly patterns, which is crucial for Quarkus native-image compatibility. It proposes these changes based on its understanding of your code and requires your explicit approval before applying them, ensuring your application survives native compilation.

Is it safe to let Atlas modify my Quarkus project files?

Yes, Atlas is designed with multiple safety layers. Every tool call is permission-gated against allow, ask, and deny rules. It drafts a read-only plan, and computes a unified diff for every file edit, requiring your explicit approval before writing any changes to your Quarkus project, including `CDI beans` or `application.properties`.

Can Atlas help me find debugging code in my Quarkus diff before committing?

Absolutely. Atlas can `grep` your working diff for common debugging leftovers like `System.out.println` or commented-out blocks across your Quarkus project files. This helps you identify and remove temporary code, ensuring a clean and production-ready commit.

How does Atlas handle `application.properties` in a Quarkus project?

Atlas reads and understands the properties defined in `application.properties`, allowing it to reason about your Quarkus application's configuration. It can suggest relevant changes or additions, always with your explicit permission, and ensures these configurations are correctly handled for build-time augmentation.

Self-review your working diff before committing in Quarkus with Atlas in 2026

Atlas empowers Quarkus developers in 2026 to catch their own mistakes in uncommitted diffs by integrating directly with the Quarkus toolchain, including `Maven` for builds, `JUnit 5 (@QuarkusTest)` for testing, and `Spotless` for formatting. This ensures a thorough self-review process before changes reach a reviewer or CI, maintaining high code quality and preventing regressions.

How does Atlas help self-review uncommitted Quarkus changes?

Atlas helps Quarkus developers review uncommitted changes by surfacing the raw `git diff` and enabling full file reads, ensuring no mistake goes unnoticed. In 2026, this process integrates directly into your terminal workflow, allowing you to scrutinize every line before it leaves your local machine, often catching 1-2 critical issues per review.

Before committing any changes in a Quarkus project, Atlas allows you to perform a comprehensive self-review of your working diff. It leverages its `bash` tool to produce the exact `git diff`, which you can then read end-to-end, rather than relying on memory of which files you touched. This is crucial because a standard diff only shows changes, potentially hiding context in untouched surrounding code. Atlas also enables you to `read` each changed Quarkus file in full, ensuring that your modifications align with the existing `CDI beans`, `JAX-RS resources`, or `application.properties` configurations. This deep contextual understanding, powered by Atlas's AST-based indexing using tree-sitter, helps you verify the change against its surroundings, preventing subtle integration issues that a line-by-line diff might miss.

How to run Quarkus tests and format code with Atlas?

Atlas runs your Quarkus project's tests and applies formatting by executing standard `Maven` commands like `./mvnw test` and `Spotless` directly. This ensures your code adheres to project standards and passes all `JUnit 5 (@QuarkusTest)` assertions, typically within 1-2 minutes for a typical module, before any commit.

A critical part of self-review in Quarkus development is verifying functionality and code style. Atlas facilitates this by allowing you to run your project's tests and apply formatting directly from the terminal. Using its `bash` tool, Atlas can execute `./mvnw test`, which triggers your `JUnit 5 (@QuarkusTest)` suite. This ensures that your changes haven't introduced regressions and that all `@QuarkusTest` cases, potentially involving `RestAssured`, pass as expected. Furthermore, Atlas can apply your project's code style by running `./mvnw spotless:apply`. This command, which uses the `Spotless` formatter, automatically corrects any formatting inconsistencies, ensuring your code adheres to the project's standards before it's committed. Both these operations are permission-gated, meaning Atlas will always ask for your explicit approval before executing these commands, giving you full control.

How to find and remove debugging leftovers in Quarkus with Atlas?

Atlas helps Quarkus developers identify and remove debugging leftovers like temporary logging or skipped tests before committing. By using its `grep` tool, you can quickly scan your uncommitted diff for common debugging patterns, ensuring a clean codebase. This process can typically find 3-5 instances of forgotten debug code in a moderately sized diff.

Debugging often leaves behind temporary code that should not be committed, such as `System.out.println` statements, commented-out blocks, or `@Disabled` `JUnit 5` tests. Atlas provides a powerful `grep` tool to help you find these leftovers within your working diff. You can instruct Atlas to search for specific patterns across your Quarkus project files, for example, `atlas grep "System.out.println" src/main/java/` to find temporary logging statements in your Java source. This proactive step ensures that your commits are clean, free of unnecessary noise, and ready for production. Atlas's ability to search code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion makes this `grep` operation highly effective, even in large codebases.

How to revert unwanted changes in a Quarkus project with Atlas?

Atlas allows Quarkus developers to safely revert unwanted changes using its session revert feature, which restores from a snapshot. This capability ensures that any accidental edits, even 10 lines deep in a `JAX-RS` resource or `application.properties` file, can be undone without manual effort, provided the session is not busy.

During the self-review process, you might discover changes that should not have been made or were introduced accidentally. Atlas provides a robust session revert mechanism to handle such situations. Every edit Atlas makes is recoverable, as it snapshots file changes as `git` patches. If you identify an unwanted change in your Quarkus project, you can use `atlas revert` to restore your working tree from a previous snapshot. This feature is designed with safety in mind: it refuses to run on a busy session, preventing a half-written turn from being rolled back mid-flight. This ensures that your Quarkus codebase remains consistent and that you can confidently experiment, knowing you can always roll back to a stable state.

What are Atlas's safety and permission features for Quarkus development?

Atlas prioritizes safety in Quarkus development through permission-gated tool calls and a read-only plan agent. Every action, from modifying a `pom.xml` to adding a `JAX-RS` resource, requires explicit approval, ensuring you maintain 100% control over your codebase and preventing unintended changes.

Atlas is built with multiple layers of safety to ensure that your Quarkus project remains under your control. Every Atlas tool call, whether it's running `Maven` commands, modifying `application.properties`, or editing `CDI beans`, is permission-gated against allow, ask, and deny rules before it runs. Before making any changes, Atlas drafts a plan in a read-only plan agent and asks for your approval before switching to a build agent. Furthermore, for every file edit, Atlas computes a unified diff and surfaces it for your approval before writing. This meticulous process ensures that you review and approve every single change, providing complete transparency and preventing any unexpected modifications to your Quarkus codebase. Atlas also connects to Model Context Protocol servers and exposes their tools to the agent, all while respecting these permission boundaries.

Step by step

01Produce the working diff for your Quarkus project using Atlas's `bash` tool: `atlas bash git diff`. Read the entire diff end to end, not just the files you remember touching, to catch all changes.
02Read each changed Quarkus file in full using Atlas's `read` tool, for example: `atlas read src/main/java/com/example/MyResource.java`. This helps check the change against its surroundings, as a diff hides untouched context.
03Grep for debugging leftovers you introduced in your Quarkus code. Use Atlas's `grep` tool, for instance: `atlas grep "System.out.println" src/main/java/` or `atlas grep "@Disabled" src/test/java/` to find temporary logging or skipped `JUnit 5 (@QuarkusTest)` cases.
04If a change should not have been made, use Atlas's session revert: `atlas revert`. This restores your Quarkus project from a snapshot, asserting the session is not busy first to prevent data loss.
05Run your Quarkus tests with `Maven` via Atlas: `atlas bash ./mvnw test`. Ensure all `JUnit 5 (@QuarkusTest)` cases pass, including those using `RestAssured`.
06Apply `Spotless` formatting to your Quarkus codebase using Atlas: `atlas bash ./mvnw spotless:apply`. Review any formatting changes before proceeding.
07Review the final diff presented by Atlas, then let Atlas apply `Spotless` before it commits, ensuring your Quarkus code is clean and formatted.
08Commit your changes through Atlas, which can stage and create commits on your behalf after all checks and approvals.

Frequently asked questions

How does Atlas handle `pom.xml` changes in Quarkus projects?: Atlas reads your `pom.xml` to understand project dependencies and build configurations, allowing it to execute `Maven` commands like `./mvnw test` and `spotless:apply` directly. Any proposed modifications to the `pom.xml` itself will be presented as a unified diff for your explicit approval before Atlas writes them.
Can Atlas run `JUnit 5 (@QuarkusTest)` tests for my Quarkus application?: Yes, Atlas can run `JUnit 5 (@QuarkusTest)` tests by invoking `./mvnw test` through its `bash` tool, surfacing the results directly in your terminal. It can also assist in adding new `@QuarkusTest` cases with `RestAssured` behind a permission prompt, ensuring comprehensive test coverage.
How does Atlas ensure code style with `Spotless` in Quarkus development?: Atlas integrates with `Spotless` by executing `./mvnw spotless:apply` before committing, ensuring your Quarkus codebase adheres to defined formatting standards. This step is permission-gated, giving you control, and helps maintain consistent code style across your project.
What Quarkus-specific files and idioms does Atlas understand?: Atlas understands Quarkus-specific files such as `pom.xml`, `application.properties`, `CDI beans`, and `JAX-RS resources`. It indexes code by AST declarations using tree-sitter, not blind line windows, allowing for precise understanding of Quarkus idioms and structures.
How does Atlas help with native-image compatibility in Quarkus?: Atlas can assist in replacing runtime reflection with build-time-friendly patterns, which is crucial for Quarkus native-image compatibility. It proposes these changes based on its understanding of your code and requires your explicit approval before applying them, ensuring your application survives native compilation.
Is it safe to let Atlas modify my Quarkus project files?: Yes, Atlas is designed with multiple safety layers. Every tool call is permission-gated against allow, ask, and deny rules. It drafts a read-only plan, and computes a unified diff for every file edit, requiring your explicit approval before writing any changes to your Quarkus project, including `CDI beans` or `application.properties`.
Can Atlas help me find debugging code in my Quarkus diff before committing?: Absolutely. Atlas can `grep` your working diff for common debugging leftovers like `System.out.println` or commented-out blocks across your Quarkus project files. This helps you identify and remove temporary code, ensuring a clean and production-ready commit.
How does Atlas handle `application.properties` in a Quarkus project?: Atlas reads and understands the properties defined in `application.properties`, allowing it to reason about your Quarkus application's configuration. It can suggest relevant changes or additions, always with your explicit permission, and ensures these configurations are correctly handled for build-time augmentation.

Try Atlas in your terminal

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

Install Atlas

Related guides

Self-Review Your Working Diff Before Committing with Atlas (2026 Workflow)

How to self-review your working diff before committing with Atlas in 2026: bash produces the diff, read checks each file, grep finds leftovers, session revert undoes bad edits.

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.

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.

Refactor a legacy module in Quarkus with Atlas in 2026

Streamline Quarkus module refactoring in 2026 with Atlas. Safely restructure old code, maintain behavior, and prevent breaking callers using Maven, JUnit 5, and Spotless.

Write Unit Tests for Untested Quarkus Code with Atlas in 2026

In 2026, use Atlas to write robust unit tests for untested Quarkus modules. Atlas understands your existing JUnit 5 (@QuarkusTest) and Maven conventions, ensuring new tests integrate direct.

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

Debug a Single Failing Test in Quarkus with Atlas in 2026

Pinpoint and fix failing Quarkus tests efficiently with Atlas. Leverage JUnit 5, Maven, and Spotless for a streamlined debugging workflow in 2026.

Upgrade a Quarkus Dependency and Fix Breakage with Atlas in 2026

In 2026, Atlas helps Quarkus developers upgrade major dependencies, fixing compile and test failures. It drives Maven, reads compiler output, and repairs code with LSP, ensuring JUnit 5 and Spotless compliance.

Browse this resource hub