I am currently setting up a Maven project for automation testing, but every time I trigger my TestNG suite, I encounter the java.lang.NoClassDefFoundError: com/google/common/collect/ImmutableMap error. It seems like a Guava dependency issue, but I have verified my pom.xml multiple times. Has anyone found a definitive way to fix this version mismatch without breaking other dependencies?
3 answers
This error almost always stems from a dependency conflict involving the Google Guava library. In modern software development, Selenium and TestNG both rely on Guava, but if different versions are being pulled in via transitive dependencies, the JVM might fail to find the ImmutableMap class at runtime. The most effective fix is to explicitly add the latest Guava dependency to your pom.xml. Alternatively, you can use the Maven Dependency Tree command to identify which library is bringing in an outdated version and exclude it. This ensures that your classpath remains clean and that the class loader finds the correct bytecode during execution.
Have you tried running mvn dependency:tree to see if there is a conflict between your Selenium-Java version and another third-party library? Sometimes a simple version exclusion in the pom file is all that's needed, but I'm curious if you've checked for multiple jar versions in your local M2 repository?
Usually, this happens because the Guava version is too old. Updating your Selenium dependency to the latest stable version (4.x or higher) typically bundles the correct version of Guava automatically.
I agree with Natalie. I had this exact same problem last month while upgrading our testing framework. Updating Selenium worked immediately because the newer versions have shifted away from certain Guava dependencies, reducing these types of classpath conflicts significantly.
Bradley, checking the local repository is a great shout. Often, Maven fails to refresh the snapshots correctly, leading to corrupted jar files. I'd recommend running mvn clean install -U after deleting the specific Guava folder in the .m2 directory. This forces a fresh download of the artifacts and usually clears up any NoClassDefFound issues that aren't related to actual code errors but rather environment inconsistencies.