How does Atlas ensure it finds every deprecated Groovy API call?

Atlas combines the `lsp` tool's `findReferences` for static usages in Groovy classes, `build.gradle`, and `Jenkinsfile` with a `grep` search for dynamic or string-based invocations. This dual approach ensures comprehensive enumeration, leaving no callsite unaddressed.

Can Atlas handle deprecated APIs used in Groovy DSL closures or Gradle scripts?

Yes, Atlas is designed to work with Groovy DSL closures and Gradle scripts. It can read your Groovy DSL closures, `@Grab` or Gradle dependencies, and any shared pipeline library, ensuring that deprecated API calls within these contexts are correctly identified and migrated.

What if a Groovy file changes while Atlas is migrating it?

Atlas's `apply_patch` tool is designed for safety. It uses context lines and `old_lines` to apply changes. If a Groovy file has drifted and the expected lines are not found, `apply_patch` will throw a 'Failed to find expected lines' error, preventing misapplication and preserving your code integrity.

How does Atlas verify the correctness of Groovy API migrations?

After each file modification, Atlas uses the `bash` tool to run `gradle test`, executing your Spock specifications. The `todowrite` entry for that callsite is only marked complete once these tests pass, ensuring functional correctness and preventing regressions in your Groovy codebase.

Does Atlas maintain Groovy code style during migration?

Yes, Atlas can apply `Spotless` with the Groovy formatter to any files it touches during the migration process. This ensures that your codebase maintains consistent formatting and adheres to your project's style guidelines, even after significant changes.

Is it safe to let Atlas modify my Groovy codebase automatically?

Atlas operates with multiple layers of safety. Every tool call is permission-gated, requiring your approval. It drafts a plan in a read-only agent first and computes a unified diff for every file edit, which you must approve before writing. This gives you full control over all changes to your Groovy project.

Can Atlas help with Groovy projects using Jenkins pipeline scripts?

Absolutely. Atlas can run in a project with a `Jenkinsfile` and read your shared pipeline library. This allows it to identify and migrate deprecated API usages within your Jenkins pipeline scripts, ensuring your CI/CD infrastructure remains up-to-date.

Migrate a Deprecated API Across Every Callsite in Groovy with Atlas in 2026

To move an entire Groovy codebase off a deprecated function or module onto its replacement without missing a caller, Atlas provides a robust, terminal-native workflow. It integrates directly with your Groovy toolchain, including `Gradle` for dependency management, `Spock (gradle test)` for verification, and `Spotless` for consistent formatting, ensuring a complete and safe migration process.

How Atlas Enumerates All Deprecated Groovy API Callsites

Identifying every callsite of a deprecated Groovy API is the critical first step in any migration, preventing missed references that could lead to runtime errors in 2026. Atlas achieves this by combining the `lsp` tool's `findReferences` operation with a `grep` cross-check.

Atlas begins by leveraging the `lsp` tool to query the language server for all references to the deprecated symbol. This provides a comprehensive list of static usages across your Groovy project, including those within `build.gradle` files, `Jenkinsfile` scripts, and Spock specifications. For dynamic or string-based invocations that the language server might miss, Atlas then performs a `grep` search across the codebase. This dual-pronged approach ensures that every single callsite, whether a direct method call in a Groovy class or a string literal in a configuration file, is identified and accounted for before any changes are made. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, which enhances the accuracy of its initial `lsp` queries.

Managing Migration Progress for Groovy Codebases with Atlas

Tracking progress across potentially hundreds of Groovy files during a large-scale API migration is essential to avoid partial work or forgotten tasks. Atlas addresses this by creating one `todowrite` entry per callsite, making partial progress visible and ensuring no caller is silently skipped in 2026.

Once all deprecated Groovy API callsites are enumerated, Atlas uses its `todowrite` tool to generate a distinct entry for each one. This transforms the migration into a series of manageable, trackable tasks. Each `todowrite` entry represents a specific location in your Groovy codebase,be it a `.groovy` source file, a `build.gradle` script, or a `Jenkinsfile`,where the deprecated API is used. This granular tracking allows you to see exactly which files have been updated and which still require attention, providing clear visibility into the overall migration status. Atlas can fan out work to subagents that can run in the foreground or in parallel background sessions, accelerating the processing of these `todowrite` entries.

Applying Safe, Context-Anchored Patches to Groovy Files

Migrating each deprecated Groovy API callsite requires precise, context-aware modifications to prevent accidental changes to drifted code. Atlas employs the `apply_patch` tool, which seeks the hunk's context and old lines, failing rather than misapplying to a file in 2026.

For each `todowrite` entry, Atlas uses the `apply_patch` tool to perform the actual migration. This tool is designed for safety: it generates a patch that includes not only the lines to be changed but also surrounding context lines and the exact `old_lines` expected. If the `apply_patch` tool cannot find the expected context or `old_lines` in the target Groovy file,indicating that the file has drifted since the initial enumeration,it will throw a 'Failed to find expected lines' error instead of attempting a potentially incorrect modification. This prevents silent corruption of your Groovy source code, `build.gradle` scripts, or Spock specifications. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, giving you full control over every change.

Verifying Groovy Migrations with Spock and Spotless

After modifying a Groovy file, immediate verification is crucial to confirm the migration's success and maintain code quality. Atlas integrates directly with your Groovy toolchain, running `gradle test` for Spock specifications and applying `Spotless` formatting after each file in 2026.

Following each `apply_patch` operation on a Groovy file, Atlas executes the affected tests using the `bash` tool. This means running `gradle test` to execute your Spock specifications, ensuring that the migrated code functions correctly and hasn't introduced regressions. Only once these tests pass is the corresponding `todowrite` entry marked as completed. Furthermore, Atlas can apply `Spotless` with the Groovy formatter to the touched files, maintaining consistent code style across your project. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, including `bash` commands like `gradle test`, providing an additional layer of safety and control.

Final Confirmation and Cleanup of Deprecated Groovy APIs

Ensuring a complete migration means confirming zero remaining usages of the deprecated Groovy API and removing its old implementation. Atlas concludes the workflow by performing a final `grep` check and assisting with the deletion of the old code in 2026.

Once all individual callsites have been migrated and their respective tests passed, Atlas performs a final `grep` search across the entire Groovy codebase for the deprecated symbol. This step serves as a robust double-check, confirming that no instances were missed, including any dynamic or string-based usages that might have been overlooked by the `lsp` tool. Upon confirming zero remaining hits, Atlas can then assist in deleting the old implementation of the deprecated function or module. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, streamlining the final cleanup and commit process for your Groovy project.

Step by step

01Enumerate all deprecated Groovy API callsites using Atlas's `lsp` tool's `findReferences` operation on the symbol, then cross-check with `grep` for dynamic usages in `.groovy` files, `build.gradle`, and `Jenkinsfile`.
02Create one `todowrite` entry per identified callsite in your Groovy codebase, ensuring every instance of the deprecated API is tracked for migration.
03Migrate each Groovy callsite using Atlas's `apply_patch` tool, which seeks the hunk's context and `old_lines` and will fail rather than misapplying to a drifted file.
04After each file modification, run the affected tests using Atlas's `bash` tool with `gradle test` for your Spock specifications, marking the `todowrite` entry complete only once tests pass.
05Have Atlas apply `Spotless` with the Groovy formatter to the touched files to maintain consistent code style.
06Finish by using Atlas's `grep` tool to confirm zero remaining hits of the deprecated symbol across your Groovy project, then delete the old implementation.

Frequently asked questions

How does Atlas ensure it finds every deprecated Groovy API call?: Atlas combines the `lsp` tool's `findReferences` for static usages in Groovy classes, `build.gradle`, and `Jenkinsfile` with a `grep` search for dynamic or string-based invocations. This dual approach ensures comprehensive enumeration, leaving no callsite unaddressed.
Can Atlas handle deprecated APIs used in Groovy DSL closures or Gradle scripts?: Yes, Atlas is designed to work with Groovy DSL closures and Gradle scripts. It can read your Groovy DSL closures, `@Grab` or Gradle dependencies, and any shared pipeline library, ensuring that deprecated API calls within these contexts are correctly identified and migrated.
What if a Groovy file changes while Atlas is migrating it?: Atlas's `apply_patch` tool is designed for safety. It uses context lines and `old_lines` to apply changes. If a Groovy file has drifted and the expected lines are not found, `apply_patch` will throw a 'Failed to find expected lines' error, preventing misapplication and preserving your code integrity.
How does Atlas verify the correctness of Groovy API migrations?: After each file modification, Atlas uses the `bash` tool to run `gradle test`, executing your Spock specifications. The `todowrite` entry for that callsite is only marked complete once these tests pass, ensuring functional correctness and preventing regressions in your Groovy codebase.
Does Atlas maintain Groovy code style during migration?: Yes, Atlas can apply `Spotless` with the Groovy formatter to any files it touches during the migration process. This ensures that your codebase maintains consistent formatting and adheres to your project's style guidelines, even after significant changes.
Is it safe to let Atlas modify my Groovy codebase automatically?: Atlas operates with multiple layers of safety. Every tool call is permission-gated, requiring your approval. It drafts a plan in a read-only agent first and computes a unified diff for every file edit, which you must approve before writing. This gives you full control over all changes to your Groovy project.
Can Atlas help with Groovy projects using Jenkins pipeline scripts?: Absolutely. Atlas can run in a project with a `Jenkinsfile` and read your shared pipeline library. This allows it to identify and migrate deprecated API usages within your Jenkins pipeline scripts, ensuring your CI/CD infrastructure remains up-to-date.

Try Atlas in your terminal

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

Install Atlas

Related guides

Migrate a Deprecated API Across Every Callsite with Atlas (2026 Workflow)

How to migrate a deprecated API across every callsite with Atlas in 2026: the lsp tool's findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.

Atlas for Groovy: A Terminal-Native AI Coding Agent for Gradle, Spock, and Jenkins in 2026

Atlas is a terminal-native AI coding agent for Groovy in 2026. It reads build.gradle closures and Jenkinsfiles, writes Spock specs, runs ./gradlew test, and applies Spotless.

Rename a symbol across the repo in Groovy with Atlas in 2026

Effortlessly rename Groovy functions, classes, or constants across your entire repository in 2026 with Atlas. Leverage lsp, grep, and edit for precise, safe refactoring in Gradle and Spock projects.

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

Catch your own mistakes in Groovy code before they reach review or CI. Atlas helps Groovy developers in 2026 self-review uncommitted diffs, run Spock tests, apply Spotless formatting, and safely revert changes.

Automate GitHub Issue and Pull Request Triage in Groovy with Atlas in 2026

Streamline GitHub issue and pull request triage for Groovy projects in 2026. Atlas integrates with Gradle, Spock, and Spotless to automate responses safely and only for trusted users.

Add a Regression Test for a Groovy Bug Fix with Atlas in 2026

Lock in Groovy bug fixes with Atlas by writing failing Spock tests, applying fixes, and verifying with Gradle. Ensure code quality with Spotless and secure changes with diff approvals.

Document a Module with a README in Groovy with Atlas in 2026

For Groovy developers in 2026, Atlas generates accurate READMEs by analyzing current source code, integrating with Gradle, Spock, and Spotless for reliable documentation.

Refactor a Legacy Groovy Module with Atlas in 2026

Streamline legacy Groovy code in 2026 using Atlas. Refactor modules without breaking callers, leveraging Spock (gradle test), Gradle, and Spotless for safety and quality.

Browse this resource hub