如何通过Maven Shading解决Guava版本冲突导致的Servlet容器部署失败问题

看起来你踩了典型的依赖版本冲突坑——容器自带的Guava 15.0和你项目里Guice依赖的高版本Guava不兼容，直接抛出了NoSuchMethodError（具体是Preconditions.checkArgument的重载方法找不到，这个方法是高版本Guava才新增的）。你选择用Maven Shade插件是完全正确的方向，但目前的配置还不够完整，我来帮你补全，彻底隔离冲突的Guava版本。

问题核心原因 #

容器的类加载器优先级更高，先加载了自带的旧版Guava（15.0），而你的Guice依赖的高版本Guava才包含那个缺失的checkArgument方法。当Guice代码尝试调用这个方法时，JVM找不到对应实现，自然就抛出了启动失败的错误。Shading的本质就是把你项目依赖的Guava类重命名到独立的包路径下，让它和容器的Guava彻底“分家”，互不干扰。

完整的Maven Shade插件配置 #

请把你现有的Shade插件配置替换成下面的完整版本，重点是添加包重定位规则：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.4</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <!-- 保留原依赖声明，避免后续构建异常 -->
                <createDependencyReducedPom>false</createDependencyReducedPom>
                <!-- 核心：重命名Guava包路径，隔离容器版本 -->
                <relocations>
                    <relocation>
                        <!-- 原Guava的根包路径 -->
                        <pattern>com.google.common</pattern>
                        <!-- 重命名后的目标包路径，替换成你项目专属的前缀 -->
                        <shadedPattern>com.yourcompany.shaded.google.common</shadedPattern>
                        <!-- 确保所有Guava子包都被重命名 -->
                        <includes>
                            <include>com.google.common.**</include>
                        </includes>
                    </relocation>
                </relocations>
                <!-- 只处理Guava依赖，避免无意义的shade操作 -->
                <artifactSet>
                    <includes>
                        <include>com.google.guava:guava</include>
                    </includes>
                </artifactSet>
            </configuration>
        </execution>
    </executions>
</plugin>

配置关键点拆解 #

1. relocations规则：这是解决冲突的核心。它会把所有com.google.common开头的类重命名为你指定的新路径，同时自动修改项目中所有依赖（比如Guice）的字节码，把对旧包路径的引用全部替换成新路径——相当于给Guava换了个“身份证”，容器再也不会把它和自带的旧版本搞混。
2. artifactSet：明确只处理Guava依赖，避免shade无关的库，既提升打包效率，也减少不必要的文件体积。
3. createDependencyReducedPom：保持false，因为我们需要保留原有的依赖声明，防止后续构建或其他模块引用时出现依赖缺失。

验证是否生效 #

打包完成后，你可以通过以下步骤确认配置生效：

1. 解压生成的WAR包，进入WEB-INF/lib目录，找到包含Guava的jar包。
2. 用反编译工具（比如JD-GUI）打开这个jar，查看类的包路径，确认已经变成你配置的com.yourcompany.shaded.google.common。
3. 重新部署到容器，观察启动日志，确认NoSuchMethodError不再出现。

额外注意事项 #

• 如果你的项目代码里有直接引用Guava的地方，完全不用担心——Shade插件会自动修改你项目代码中的引用，把com.google.common替换成新的包路径。
• 要是容器有强制加载旧版Guava的模块配置（比如JBoss/Wildfly的modules目录配置），可能需要调整容器的模块优先级，但Shading通常已经能解决绝大多数场景的冲突。

内容来源于stack exchange