Resolving deprecated com.google.common (Guava) library usage detected during deployment

Last update: June 27, 2026

AEM deployments fail or trigger Actions Center alerts when the deprecated com.google.common (Google Guava) API is detected. Cloud Manager inspects all OSGi imports — including transitive and test-scope dependencies — so the warning appears even when a project doesn’t explicitly depend on Guava. The fix depends on the source: outdated ACS AEM Commons, Core Components example packages, test libraries, or custom code referencing Guava utilities directly. Removing or replacing the Guava dependency, then redeploying, clears the alert and closes the Actions Center incident.

Description description

Issue: Cloud Manager flags deprecated com.google.common (Guava) usage during deployment

Description

Cloud Manager and the AEM API deprecation scanner flag deprecated usage of com.google.common.*. The warning appears even when a project has no explicit Guava dependency, because Cloud Manager inspects OSGi imports including transitive and test-scope dependencies. The issue affects AEMaaCS, Managed Services, and On-Premise environments.

Environment:

Adobe Experience Manager as a Cloud Service (AEMaaCS)
AEM Managed Services (AMS)
AEM 6.5 LTS On-Premise
Cloud Manager (build and code quality pipelines)

Issue/Symptoms:

Actions Center alert: Deprecated Library Detected — com.google.common
Cloud Manager analyser log warnings referencing packages such as com.google.common.collect
Pipeline Code Quality step pauses or fails due to deprecated library usage
OSGi inspector confirms bundles import com.google.common.* even when it’s only a transitive test dependency

Root cause:

The com.google.common API is fully deprecated and scheduled for removal in AEM as a Cloud Service. Cloud Manager flags any bundle that imports com.google.common.*, regardless of whether the dependency is explicit, transitive, or test-scope. Deprecated usage can originate from outdated ACS AEM Commons versions, Core Components example packages, io.wcm testing libraries, slf4j-test, sling-mock, Asset Share Commons, or custom code using Guava utilities such as Lists.partition(). On AEM 6.5 LTS and On-Premise, Guava is no longer shipped and can’t be installed as a standalone bundle due to sling_bootstrap.txt restrictions.

How to confirm

Run the following in your core bundle module to identify all dependencies pulling in Guava, including test-scope:

code language-none
`mvn dependency:tree -Dincludes=com.google.guava:,com.google.common:`

Review the output to confirm whether the source is direct or transitive, and match it to one of the remediation paths below.
Cross-reference with Cloud Manager analyser logs to confirm which bundles import com.google.common.*.

Resolution resolution

Custom code using Guava (AEMaaCS, AMS, On-Prem): Replace com.google.common utilities with JDK or Apache Commons Collections 4 equivalents. For example, replace Lists.partition() with a Java stream-based batching approach. Verify by searching the project:

code language-none
`grep -R "com.google.common" ./src`

If removing Guava breaks functionality in the short term, temporarily embed your own Guava version (see step 5) and plan refactoring.
2. ACS AEM Commons pulling Guava (AEMaaCS): Update ACS AEM Commons to at least version 6.11.0 and ensure classifier=cloud is set per official guidance. Rebuild and check the analyser output to confirm Guava is no longer reported.
3. Core Components example packages (AEMaaCS): Remove all core.wcm.components.examples.* packages from your all module. Re-run mvn clean install and inspect the built content package to confirm the examples package is gone. Check that it wasn’t reintroduced by parent POM inheritance.
4. Test-scope transitive dependencies (AEMaaCS): Remove or replace test libraries such as slf4j-test and io.wcm.testing.aem-mock.* that transitively reference Guava. Re-run mvn dependency:tree to confirm com.google.common no longer appears. If the leak persists, configure the bundle plugin to exclude com.google.common.* from Import-Package.
5. AEM 6.5 On-Prem or AMS — embed Guava inside a custom bundle: If Guava is required, embed or shade it inside a custom bundle rather than installing it as a standalone bundle (standalone installation is blocked by sling_bootstrap.txt). Ensure the bundle doesn’t export its Guava packages. Deploy and confirm the custom bundle shows an Active state in the Web Console.
6. Rebuild and redeploy: Run a full Cloud Manager pipeline (AEMaaCS) or deploy the OSGi bundle through the AMS/On-Prem deployment process. Confirm the Code Quality step completes without reporting deprecated com.google.common.* warnings.
7. Revalidate: For AEMaaCS, running the full Cloud Manager pipeline re-triggers the same scanner that creates Actions Center incidents. If no deprecated usage is detected, the incident resolves automatically. Refresh Actions Center to confirm the incident is closed.

Validation

Run mvn dependency:tree again and confirm no modules import com.google.common.*.
Check Cloud Manager analyser logs after deployment to confirm no deprecated library warnings remain.
Confirm Actions Center no longer generates deprecated-library incidents.
Verify no custom bundle imports com.google.common.* using OSGi Web Console or pipeline logs.

recommendation-more-help

experience-cloud-kcs-help-kbarticles