AEM Analyser Enhancement: Active Code Remediation (Automated PRs for Deprecated APIs)

Hi Team,

Last week, my team needed to deploy an urgent, time-sensitive hotfix. The fix itself was incredibly minor just a two-line null-check update inside a core OSGi service. We tested it locally against the latest SDK, the PR was approved, and we kicked off the Cloud Manager production pipeline.

Twenty minutes later, the pipeline abruptly halted with a Hard Failure at the Code Quality step. I pulled the logs, expecting a missed unit test, but instead found this:

[WARNING] [region-deprecated-api] ... Usage of deprecated package found: com.day.cq.commons.jcr.JcrConstants. For removal: 2026-06-11
[ERROR] Rule region-deprecated-api failed. Build halted.

Because of the strict API deprecation gates rolled out in the recent 2026 releases, what used to be a passive log warning had instantly become a deployment blocker.

The frustrating part? The code that failed was not even part of our hotfix. It was an old legacy utility class deep in our core Java bundle that hadn't been modified in three years. Because Cloud Manager runs the aemanalyser-maven-plugin against the entire compiled codebase using the absolute latest cloud API surface, a background deprecation rule crossed the hard-fail threshold right as we were trying to deploy a critical backend fix.

We all know why the recent AEMaaCS updates are strictly enforcing cloud-native standards. The move to hard-fail pipelines for deprecated API usage makes sense for platform stability you can't safely roll out zero-day patches if our custom code is still tethered to old, internal classes. But the current implementation is creating a massive bottleneck for development teams.

Right now, when the AEM Analyser flags a legacy ResourceResolver method or an obsolete Day Commons import, it just kills the pipeline. For the dev team, this means dropping current sprint work, pulling the codebase locally, digging through Adobe docs to find the modern equivalent API, manually rewriting it, running local Maven builds, and pushing a new commit. It turns minor technical debt into a complete sprint-blocker, delaying critical user stories.

The Idea:

The AEM Analyser already has the exact context of what is broken, and it knows the modern API package required to fix it. My proposal is to expand the aemanalyser-maven-plugin from a passive linter into an active formatting and refactoring tool.

Instead of just throwing an error and halting the ecosystem, let's give the plugin the ability to actively patch the deprecated APIs it finds. To make this practical and secure, we can handle this on two fronts:

1. Locally via mvn aemanalyser:fix

Developers shouldn't have to wait for a pipeline failure. We should be able to run a new target directly in our local terminal during active development:

mvn clean install aemanalyser:fix -PautoInstallPackage

The plugin runs its standard scans, but instead of failing the build on deprecations, it applies the structural fix directly to the local source files. The developer instantly sees the git diff, verifies it, and commits clean code before it ever touches Git.

2. Inside Cloud Manager (The "Secure PR" Fallback)

If legacy code does slip through to Cloud Manager, we keep a strict Human-in-the-Loop model rather than blindly auto-merging code to the main branch:

• AST-Based Refactoring: For 80% of standard deprecations (like swapping com.day.cq.commons.jcr.JcrConstants for org.apache.jackrabbit.JcrConstants), the plugin uses an Abstract Syntax Tree (AST) engine like OpenRewrite under the hood. It refactors the Java structurally and deterministically without messing up custom formatting.

• Targeted AI Patching: For complex architectural shifts, an isolated, AEM-trained LLM drafts a scoped logic translation matching the current cloud API surface.

• The Sandbox Test: Before proposing anything, the engine runs the project's existing JUnit test suite against the refactored code inside the build container. If the tests fail, the engine safely aborts and defaults to a standard pipeline failure.

• The PR Handoff: If the unit tests pass, Cloud Manager pauses the pipeline, commits the fixes to an isolated branch, and automatically opens a Pull Request back to our repository (e.g., "aem-analyser-auto-fix/deprecation-cleanup").

Think About the Workflow Difference:

• How it works today: A custom Sling Model uses legacy Felix SCR annotations. Cloud Manager fails the build. The backend developer spends hours manually refactoring them to modern OSGi R7 Declarative Services annotations (@Component, @AttributeDefinition), rebuilding, and re-pushing. Sprint velocity takes a direct hit over unrelated legacy code.

• How it should work: The analyzer flags the Felix annotations. The plugin's remediation engine rewrites them to OSGi R7 standards inside the build container, runs the JUnit tests to confirm zero regression, and generates a PR. A senior architect reviews the diff, hits merge, and the pipeline resumes automatically.

Quick Comparison

The Win-Win

Adobe already has the DNA for this in its history, from the old AEM Modernization Tools (Classic-to-Touch UI) to the cloud migration CLI plugins (Repository Modernizer). Bringing this capability directly into the day-to-day lifecycle of the AEM Analyser is the next logical step.

Adobe wants customers off legacy APIs so the underlying infrastructure can be upgraded seamlessly without breaking production environments. We want to deliver business features without fighting the CI/CD pipeline. By shifting the AEM Analyser from a tool that merely reports errors to a tool that actively generates secure, test-validated solutions, Adobe removes the final layer of friction in maintaining a truly evergreen cloud platform.

Would love to hear the product team's thoughts on getting this added to the plugin roadmap!


Thanks 

Partyush