How to manage Guava dependencies during AEM 6.5 LTS upgrade? | Community
Skip to main content
R
Rajumuddana
Level 4
March 14, 2026
Solved

How to manage Guava dependencies during AEM 6.5 LTS upgrade?

  • March 14, 2026
  • 3 replies
  • 195 views

Hi all,

I hope you are doing well!

 

This is continution to 

while upgrading to AEM 6.5 LTS i’m facing challenges with guava library replacement/alternatives.

as per the LTS analyzer guidance, 

“The `15.0.0.0002` bundle version of Guava is no longer available out of the box in AEM 6.5 LTS due to critical security vulnerabilities. Please update and use latest non-vulnerable version of guava.”, so started with using latest versions with no vulnerabilities.

<!-- Source: https://mvnrepository.com/artifact/com.google.guava/guava -->

<dependency>

    <groupId>com.google.guava</groupId>

    <artifactId>guava</artifactId>

    <version>33.5.0-jre</version>

    <scope>compile</scope>

</dependency>

 

This is working at Java side but not at AEM instance, because there is no such library provided by Adobe runtime, so we need to embed this ourselves in our application generated bundle, this is failed because ‘com.google.guava’ bundle is a multi-release and the issue is  “JAR (like Guava 33.5.0-jre) in your built package. The filevault-package-maven-plugin and FastClasspathScanner cannot handle Java 9+ module-info.class files, resulting in the scan failure”.

So the suggestion was to use lower version + non multi-release bundle with no vulnerabilities, so switched to 

<!-- Source: https://mvnrepository.com/artifact/com.google.guava/guava -->

<dependency>

    <groupId>com.google.guava</groupId>

    <artifactId>guava</artifactId>

    <version>32.0.1-jre</version>

    <scope>compile</scope>

</dependency>

 

Still failed to embed as this is not OSGI bundle, to make to work tried an approach with ‘maven-shade-plugin’ in POM.xml, but didn’t work.

now, i’m thinking the next steps would be 

  1. Make the embed work.
  2. Use the wrapper ‘org.apache.servicemix.bundles:org.apache.servicemix.bundles.guava’ (even tried this, but maven somehow failed download the dependency from repo, though that is existed in maven central)
  3. Completely migrate away from Guava library

FI:

I’m using:  aem-6.6.1.jar and same uber.jar, uber-apis.jar along with Java 17.

The error:

org.apache.lucene.index.ThreadAffinityDocumentsWriterThreadPool@2f1cd9b3_readerPooling=false_perThreadHardLimitMB=1945_useCompoundFile=true_writer=org.apache.lucene.util.SetOnce@5fe6ea4f_
14.03.2026 02:09:43.961 *ERROR* [qtp1339066269-1825] org.apache.felix.webconsole Cannot start
org.osgi.framework.BundleException: Unable to resolve abc.core [699](R 699.13): missing requirement [abc.core [699](R 699.13)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.cache)(version>=32.0.0)(!(version>=33.0.0))) [caused by: Unable to resolve com.google.guava [705](R 705.0): missing requirement [com.google.guava [705](R 705.0)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.util.concurrent.internal)(version>=1.0.0)(!(version>=2.0.0)))] Unresolved requirements: [[abc.core [699](R 699.13)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.cache)(version>=32.0.0)(!(version>=33.0.0)))]

let me know i’m not on right direction.

 

Thanks,

Raju.

Best answer by MukeshYadav_

Hi, best and long term fix is to remove gauav as alternative methods are avaliable in java itself.

Guava Java Replacement
Lists.newArrayList() new ArrayList<>()
ImmutableList.of() List.of()
Optional java.util.Optional
Preconditions.checkNotNull Objects.requireNonNull
Joiner String.join
Splitter String.split


If refactoring out Guava completely is too large of a task right now, you can make your current approach work by providing the missing failureaccess dependency.
You can try deploying both Guava and Failureaccess as standalone OSGi bundles into your AEM install folder via your all or ui.apps package.

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>32.0.1-jre</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>failureaccess</artifactId>
    <version>1.0.1</version>
    <scope>provided</scope>
</dependency>

Embed in ui.apps or all

<plugin>
    <groupId>org.apache.jackrabbit</groupId>
    <artifactId>filevault-package-maven-plugin</artifactId>
    <configuration>
        <embeddeds>
            <embedded>
                <groupId>com.google.guava</groupId>
                <artifactId>guava</artifactId>
                <target>/apps/abc/install</target>
            </embedded>
            <embedded>
                <groupId>com.google.guava</groupId>
                <artifactId>failureaccess</artifactId>
                <target>/apps/abc/install</target>
            </embedded>
        </embeddeds>
    </configuration>
</plugin>


Note: Ensure your abc.core bundle's bnd-maven-plugin (or maven-bundle-plugin) has <Import-Package>com.google.common.*;version="[32.0,33)",*</Import-Package> to wire it correctly.

Thanks

3 replies

MukeshYadav_
Community Advisor
MukeshYadav_Community AdvisorAccepted solution
Community Advisor
March 14, 2026

Hi, best and long term fix is to remove gauav as alternative methods are avaliable in java itself.

Guava Java Replacement
Lists.newArrayList() new ArrayList<>()
ImmutableList.of() List.of()
Optional java.util.Optional
Preconditions.checkNotNull Objects.requireNonNull
Joiner String.join
Splitter String.split


If refactoring out Guava completely is too large of a task right now, you can make your current approach work by providing the missing failureaccess dependency.
You can try deploying both Guava and Failureaccess as standalone OSGi bundles into your AEM install folder via your all or ui.apps package.

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>32.0.1-jre</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>failureaccess</artifactId>
    <version>1.0.1</version>
    <scope>provided</scope>
</dependency>

Embed in ui.apps or all

<plugin>
    <groupId>org.apache.jackrabbit</groupId>
    <artifactId>filevault-package-maven-plugin</artifactId>
    <configuration>
        <embeddeds>
            <embedded>
                <groupId>com.google.guava</groupId>
                <artifactId>guava</artifactId>
                <target>/apps/abc/install</target>
            </embedded>
            <embedded>
                <groupId>com.google.guava</groupId>
                <artifactId>failureaccess</artifactId>
                <target>/apps/abc/install</target>
            </embedded>
        </embeddeds>
    </configuration>
</plugin>


Note: Ensure your abc.core bundle's bnd-maven-plugin (or maven-bundle-plugin) has <Import-Package>com.google.common.*;version="[32.0,33)",*</Import-Package> to wire it correctly.

Thanks

    R
    RajumuddanaAuthor
    Level 4
    March 16, 2026

    Hi ​@MukeshYadav_ ,

    Thanks for your response!

     

    I did try the approach you mentioned above.

    I think, this approach  addressed some of the guava issues, but still i see  "com.google.schemaorg.*" is missing,
    when i tried in use below dependency to address above issue, i found this dependency has a transtive dependency of google guava (old version)

                <dependency>
                    <groupId>com.github.mautini</groupId>
                    <artifactId>schemaorg-java</artifactId>
                    <version>1.0.1</version>
                </dependency>


    https://github.com/mautini/schemaorg-java/blob/master/build.gradle.


    do you have any suggession for this?

     

    Thanks,

    Raju.

    R
    RajumuddanaAuthor
    Level 4
    March 23, 2026

    Hi ​@MukeshYadav_ ,

    In the place of ‘mautini’ i’m using ‘com.weedow’ library, to addess schemaorg without Guava dependency.

    however after resolving all those dependencies issues, my bundles are up, but during validation i found a strange issue that the annotations(ike @Self, @SlingObject & @ChildResource, @OSGiService ..etc) we frequently use are not working.

     

    Thanks,

    Raju

    AmitVishwakarma
    Community Advisor
    AmitVishwakarmaCommunity Advisor
    Community Advisor
    March 14, 2026

    Hi ​@Rajumuddana 

    You're hitting two separate problems:

    • AEM 6.5 LTS removed the Guava 15 wrapper, so any bundle importing com.google.common.* with version ranges tied to 15.x will fail.
    • Guava 33.x needs an extra bundle (failureaccess), which is why your com.google.guava bundle itself is unresolved.

    Try below pattern and avoids all the multi‑release / OSGi wiring pain.

    1. Clean up old Guava

    On the LTS instance:

    • Uninstall/stop any old wrapper or bundles that export Guava 15:
      • com.adobe.granite.osgi.wrapper.guava-15.0.0-0002
      • Any 3rd‑party bundles exporting com.google.common.* for 15.x
    • Rebuild your custom bundle(s) so they no longer import com.google.common.* from the framework (we'll embed it privately next).

    2. Bring your own Guava privately (recommended pattern)

    In every bundle that uses Guava (your abc.core), add these dependencies:

    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>33.5.0-jre</version>
    </dependency>

    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>failureaccess</artifactId>
      <version>1.0.3</version>
    </dependency>

    failureaccess provides com.google.common.util.concurrent.internal – without it you get exactly the "missing requirement … util.concurrent.internal" error you pasted.

     

    Now shade + relocate Guava so OSGi never sees com.google.common.* at all:

    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-shade-plugin</artifactId>
      <version>3.5.1</version>
      <executions>
        <execution>
          <phase>package</phase>
          <goals><goal>shade</goal></goals>
          <configuration>
            <createDependencyReducedPom>false</createDependencyReducedPom>
            <relocations>
              <relocation>
                <pattern>com.google.common</pattern>
                <shadedPattern>com.mycompany.libs.guava</shadedPattern>
              </relocation>
            </relocations>
          </configuration>
        </execution>
      </executions>
    </plugin>

    Result:

    • Your bundle's bytecode uses com.mycompany.libs.guava.*, not com.google.common.*.
    • The OSGi manifest no longer contains Import-Package: com.google.common.*, so no Guava wiring errors and no dependency on Adobe's removed wrapper.
    • FileVault never has to scan module-info.class directly – it just sees your shaded bundle – so the multi‑release JAR issue disappears.

    This directly fixes:

    missing requirement osgi.wiring.package; (&(osgi.wiring.package=com.google.common.cache)(version>=32.0.0)(!(version>=33.0.0)))
    ...
    missing requirement ... com.google.common.util.concurrent.internal

    because those imports don't exist anymore.

    3. Remove version‑ranged Guava imports from your bundle

    If you currently have explicit import‑version constraints (via maven-bundle-plugin or bnd), remove them for com.google.common.*:

    # in bnd instructions
    -importpackage: !com.google.common.*,*

    After shading, there should be no import for those packages at all—verify in the built bundle's MANIFEST.MF or Felix Web Console.

    4. Long‑term: plan to migrate off Guava

    Adobe's official direction for LTS/Cloud is:

    If you insist on a shared Guava bundle (not shaded)

    Then you must:

    • Wrap both guava:33.5.0-jre and failureaccess:1.0.3 as proper OSGi bundles (via bnd-maven-plugin or maven-bundle-plugin).
    • Install both on AEM.
    • Make sure your imports don't pin to the old 15.x range (let bnd generate imports or set [33.5.0,34)).

    But shading is simpler, safer, and avoids future analyzer rules.

    Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
    R
    RajumuddanaAuthor
    Level 4
    March 16, 2026

    Hi ​@AmitVishwakarma ,

    Thanks for your response.


    I did try your solution, but still i'm facing an issue(If i understood it correctly this is related to 'multi-release' bundle)

    [ERROR] Failed to execute goal org.apache.jackrabbit:filevault-package-maven-plugin:1.0.3:analyze-classes (default-analyze-classes) on project abc.ui.apps: Error while analysing imports: Failed to scan the classpath: java.util.concurrent.ExecutionException: java.lang.RuntimeException: Unknown constant pool tag [I@4ed84c8a in classfile META-INF/versions/9/module-info.class (element size unknown, cannot continue reading class. Please report this on the FastClasspathScanner GitHub page. -> [Help 1]


    while running  mvn clean install -PautoInstallPackage -PautoInstallPackagePublish -Padobe-public -Dmaven.test.skip=true to build, deploy.

    my root, core pom.xml has below as you mentioned
               

    <dependency>
                    <groupId>com.google.guava</groupId>
                    <artifactId>guava</artifactId>
                    <version>33.5.0-jre</version>
                </dependency>
                <dependency>
                    <groupId>com.google.guava</groupId>
                    <artifactId>failureaccess</artifactId>
                    <version>1.0.3</version>
                </dependency>


                
    and

                           

    <plugin>
                                <groupId>org.apache.maven.plugins</groupId>
                                <artifactId>maven-shade-plugin</artifactId>
                                <version>3.5.1</version>
                                <executions>
                                    <execution>
                                        <phase>package</phase>
                                        <goals><goal>shade</goal></goals>
                                        <configuration>
                                            <createDependencyReducedPom>false</createDependencyReducedPom>
                                            <relocations>
                                                <relocation>
                                                    <pattern>com.google.common</pattern>
                                                    <shadedPattern>com.abc.shade.guava</shadedPattern>
                                                </relocation>
                                            </relocations>
                                        </configuration>
                                    </execution>
                                </executions>
                            </plugin

    >
    I did comment all the existed guava (<groupId>com.google.guava</groupId>) dependencies and cleaned up/ freshly pulled dependencies using below command
    "rm -rf ~/.m2/repository && mvn clean install"

    am i missing anything here?

     

    Thanks,

    Raju.

    TarunKumar
    Community Advisor
    TarunKumarCommunity Advisor
    Community Advisor
    March 16, 2026

    HI ​@Rajumuddana ,

     

    • Your bundle abc.core imports com.google.common.cache with a strict version range [32.0.0,33.0.0), so it was compiled against Guava 32.x. The AEM runtime tries to satisfy that by resolving the com.google.guava bundle. However, Guava 32.x also has an internal package com.google.common.util.concurrent.internal that your runtime does not provide or is at a different version than required [1.0.0,2.0.0), causing the resolution to fail. In short: you’re binding to Guava 32.x APIs that rely on internal packages not offered by the Guava bundle available in your AEM LTS runtime.

    Why this often happens during AEM upgrades

    • The AEM LTS runtime provides a specific Guava version. Your code’s Import-Package ranges are pinned to a newer Guava (32.x), or a different Guava is being brought in via transitive deps. The OSGi resolver can’t match the internal package constraints.

     

    Two main resolution strategies

    Option A (preferred): Align to the AEM-provided Guava

    • Recompile against the Guava version that AEM LTS provides and avoid embedding Guava.
    • Adjust your bundle’s Import-Package to avoid pinning to 32.x if the platform provides an earlier version. Allow a wider range that includes the platform version.
    • Remove any transitive/embedded Guava coming from your dependencies so your bundle uses the platform’s Guava only.

    Option B: Isolate a newer Guava with shading (if you truly need 32.x APIs)

    • Add Guava as a dependency but relocate its packages using the Maven Shade Plugin so OSGi does not attempt to resolve against the system Guava.
    • After shading, your code will import e.g., your.org.shaded.com.google.common.* instead of com.google.common.*, eliminating package wiring conflicts.
    • Do not export shaded Guava packages.

     

     

    -Tarun

    Terms & ConditionsAccessibility statement

    Loading footer...