本文详解如何避免因自定义 JAR（如 oms.jar、cms.jar）内嵌不同版本 Jackson 导致的 InvalidDefinitionException，通过统一依赖版本、合理使用 和排除策略，实现兼容性与可维护性的平衡。

本文详解如何避免因自定义 jar（如 oms.jar、cms.jar）内嵌不同版本 jackson 导致的 `invaliddefinitionexception`，通过统一依赖版本、合理使用 `` 和排除策略，实现兼容性与可维护性的平衡。

在 Maven 多模块或集成第三方私有 JAR 的项目中，一个典型痛点是：主应用显式声明了 jackson-databind:2.6.1，而引入的 oms.jar 和 cms.jar 内部又打包了旧版（如 2.3.x 或 2.5.x）Jackson 类——这会导致运行时类加载冲突，抛出 com.fasterxml.jackson.databind.exc.InvalidDefinitionException。根本原因并非“重复引入”，而是多个不兼容的 Jackson 版本共存于 classpath，JVM 加载了不匹配的 ObjectMapper、注解处理器或模块注册逻辑，引发序列化/反序列化失败。

✅ 正确解法：统一版本 + 精准管控，而非简单排除

你当前通过 移除子 JAR 中的 Jackson 是“治标”方案，虽能临时规避异常，但存在严重隐患：

• 若 oms.jar 内部依赖特定 Jackson 行为（如某旧版 @JsonCreator 解析逻辑），移除后可能引发 NoClassDefFoundError 或静默功能异常；
• 维护成本高：每次升级 oms.jar 都需手动校验并更新 exclusion 列表；
• 违背依赖传递原则，破坏可重现构建。

推荐采用分层治理策略：

1. 优先使用 锁定全项目 Jackson 版本

在 pom.xml 的 中声明统一版本，强制所有模块（包括 oms.jar、cms.jar 及其 transitive 依赖）解析为同一套 Jackson：

<dependencymanagement><dependencies><!-- 统一管理 Jackson 核心版本 --><dependency><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-core</artifactid><version>2.12.7</version><!-- 推荐升级至 2.12+（LTS），兼容性更强 --></dependency><dependency><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-databind</artifactid><version>2.12.7</version><exclusions><exclusion><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-core</artifactid></exclusion><exclusion><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-annotations</artifactid></exclusion></exclusions></dependency><dependency><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-annotations</artifactid><version>2.12.7</version></dependency></dependencies></dependencymanagement>

✅ 优势：无需修改 oms.jar/cms.jar 源码，Maven 在解析依赖树时自动“降级”或“升级”其传递依赖，确保最终 classpath 中仅存在 2.12.7 一套 Jackson。

2. 验证兼容性：检查 oms.jar/cms.jar 是否支持新版本

Jackson 2.12 对 2.6+ 具备良好的向后兼容性（尤其在核心序列化逻辑上），但需确认两点：

GPTPLUS

一款AI翻译工具，主要用于GPTPLUS, 由GPT-4和GPT-3.5支持，为您的写作、翻译、代码分析和问答需求提供最准确、有效的AI反馈，适合需要提升相关任务效率的用户。

下载

• oms.jar 是否使用了已废弃的 API（如 SerializationConfig.with(...) → 已迁至 ObjectMapper.configure(...)）；
• 是否依赖特定版本的 jackson-module-jsonSchema（注意该模块需与 jackson-databind 主版本对齐）。

可通过以下命令生成依赖树并定位冲突点：

mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind

若输出中仍出现旧版本（如 2.6.1），说明 oms.jar 声明了 compile 范围的强依赖，此时需在对应 中添加 —— 但这是兜底手段，非首选：

<dependency><groupid>com.oms</groupid><artifactid>oms</artifactid><version>1.1.6</version><exclusions><!-- 仅当 dependencyManagement 无效时启用 --><exclusion><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-core</artifactid></exclusion><exclusion><groupid>com.fasterxml.jackson.core</groupid><artifactid>jackson-databind</artifactid></exclusion></exclusions></dependency>

3. 构建时验证：启用 Maven 的 dependency convergence 检查

在 中添加 maven-enforcer-plugin，防止未来意外引入冲突版本：

<plugin><groupid>org.apache.maven.plugins</groupid><artifactid>maven-enforcer-plugin</artifactid><version>3.4.1</version><executions><execution><id>enforce-dependency-convergence</id><goals><goal>enforce</goal></goals><configuration><rules><dependencyconvergence></dependencyconvergence></rules></configuration></execution></executions></plugin>

启用后，若存在多个 Jackson 版本，构建将直接失败，并清晰提示冲突路径，便于快速定位问题源头。

⚠️ 关键注意事项

• 勿盲目升级到 Jackson 3.x：Jackson 3.0 是重大重构（模块重命名、API 不兼容），与 2.x 完全不兼容，现有 oms.jar/cms.jar 几乎必然崩溃。
• provided 范围不适用此场景：provided 仅适用于容器（如 Tomcat）预置的依赖（如 servlet-api），Jackson 是业务代码直接调用的库，必须打包进 WAR。
• 自定义 JAR 应发布为 Maven 依赖：长期建议推动 oms/cms 团队将其工程改造为标准 Maven 模块，发布到私有仓库，通过 compile 声明，而非提供黑盒 JAR——这才能彻底解决版本失控问题。

综上，以 锁定版本为核心，辅以依赖收敛检查与必要时的精准排除，是兼顾稳定性、可维护性与工程规范的最佳实践。既避免了“一刀切 exclusion”带来的隐性风险，也消除了运行时 Jackson 版本混乱的根本诱因。