企业官网建设流程全解析

• 任务调度
• 大数据
• 后端
• 前端

dolphinscheduler-bom是 Apache DolphinScheduler 仓库中专用于统一管理第三方依赖版本的 Maven BOM（Bill of Materials）模块。本文以 dolphinscheduler-bom/README.md 为主线，结合该模块的 pom.xml 及仓库内多个子模块的实际使用方式，完整讲解 BOM 的导入方法、版本覆盖机制、依赖族构成、Profile 切换与排除设计，帮助你理解并复用 DolphinScheduler 的这套依赖治理方案。

什么是 BOM，DolphinScheduler 为什么需要它

在 Maven 多模块工程中，一个常见痛点是：每个模块都各自声明依赖版本，导致版本号分散、难以统一升级，还容易因传递依赖冲突产生运行时问题。BOM（Bill of Materials）是一种packaging为pom的特殊构件，它只负责在<dependencyManagement>中集中声明一批依赖及其版本，本身不产出任何可执行内容，供其他工程以import方式引入。

在 DolphinScheduler 的仓库结构中，根 pom.xml 在<dependencyManagement>中管理着仓库内部各模块（如dolphinscheduler-master、dolphinscheduler-worker、dolphinscheduler-api等）的版本，而 dolphinscheduler-bom/pom.xml 则专门负责第三方依赖的版本治理。二者分工明确：

• 根pom.xml：定义内部模块间依赖与构建插件、公共测试依赖；
• dolphinscheduler-bom：集中管理 Netty、Spring Boot、MyBatis-Plus、Quartz、Jackson、Hadoop、Spark 等第三方库版本，并嵌套导入多个官方 BOM。

从源码看，dolphinscheduler-bom自身的坐标定义在 dolphinscheduler-bom/pom.xml#L20-L28：其父工程是org.apache.dolphinscheduler:dolphinscheduler（当前版本为dev-SNAPSHOT），packaging为pom，即纯版本管理模块。

在自己的项目中导入 dolphinscheduler-bom

原 README 给出了标准的导入方式：当你希望在自己的工程里使用任意dolphinscheduler-xx模块，同时又不想手工维护其传递依赖的版本时，可以在dependencyManagement中按如下方式导入：

<dependencyManagement> <dependencies> <dependency> <groupId>org.apache.dolphinscheduler</groupId> <artifactId>dolphinscheduler-bom</artifactId> <version>${dolphinscheduler.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

关键点说明：

• <type>pom</type>：告诉 Maven 这是一个 BOM 构件而非普通 JAR；
• <scope>import</scope>：将 BOM 中<dependencyManagement>的声明合并进当前工程的依赖管理中，此后声明被管理的依赖时无需再写版本号；
• ${dolphinscheduler.version}：应替换为你实际使用的 DolphinScheduler 发布版本。

导入之后，你的工程即可直接声明dolphinscheduler-common、dolphinscheduler-task-api等模块及其第三方依赖而不带版本。仓库内部正是这样实践的——例如 dolphinscheduler-common/pom.xml#L31-L41 和 dolphinscheduler-dao/pom.xml#L29-L39 都在各自的<dependencyManagement>中以import方式引入dolphinscheduler-bom，随后在<dependencies>中直接使用无版本号的依赖声明，如commons-io、httpclient、guava、mybatis-plus等。

覆盖 BOM 中定义的版本

原 README 明确说明：如果你希望对 BOM 中某个依赖的版本进行覆盖，可以直接在当前模块自己的dependencyManagement中为该依赖显式声明版本。Maven 遵循就近优先原则——当前 POM（或当前模块的父 POM）中显式声明的版本优先级高于通过import引入的 BOM。

例如，BOM 默认将guava版本锁定为31.1-jre（见 dolphinscheduler-bom/pom.xml#L546-L550），如果你的项目因安全或功能需要改用其他版本，可在自己的dependencyManagement中补充：

<dependencyManagement> <dependencies> <!-- 导入 BOM --> <dependency> <groupId>org.apache.dolphinscheduler</groupId> <artifactId>dolphinscheduler-bom</artifactId> <version>${dolphinscheduler.version}</version> <type>pom</type> <scope>import</scope> </dependency> <!-- 覆盖 BOM 中 guava 的版本 --> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>32.0.0-jre</version> </dependency> </dependencies> </dependencyManagement>

需要留意的是，覆盖版本属于"局部特化"，会脱离 DolphinScheduler 官方验证过的依赖组合，建议仅在确有需求（如修复 CVE、适配内部组件）时使用，并自行做好兼容性回归验证。

BOM 的核心依赖族与版本清单

dolphinscheduler-bom/pom.xml 通过<properties>集中声明版本，再在<dependencyManagement>中引用这些属性，实现"一处定义、全局生效"。当前仓库（dev-SNAPSHOT）中几个核心依赖族及版本如下：

完整的属性定义位于 dolphinscheduler-bom/pom.xml#L30-L127，覆盖范围还包括：ZooKeeper/Curator、etcd（jetcd）、gRPC、Protostuff、POI、Hive JDBC、Kyuubi JDBC、多种数据库驱动（MySQL、Oracle、PostgreSQL、SQL Server、Presto/Trino、ClickHouse、Snowflake、Redshift、达梦、Vertica、HANA 等）、Testcontainers、Fabric8 Kubernetes Client、Casdoor 等，与 DolphinScheduler 的调度、数据源插件、任务插件、告警、存储等模块的技术栈一一对应。

嵌套导入官方 BOM 的分层设计

dolphinscheduler-bom并未为所有依赖手写版本，而是对生态成熟的框架直接嵌套导入其官方 BOM，避免重复造轮子。从 dolphinscheduler-bom/pom.xml 可以看到以下<scope>import</scope>的 BOM 依赖：

• io.netty:netty-bom（版本 4.1.53.Final，见 pom.xml#L143-L150）；
• org.springframework.boot:spring-boot-starter-parent（版本 2.7.3，见 pom.xml#L157-L164），Spring 生态各依赖版本由它统一接管；
• io.grpc:grpc-bom（版本 1.41.0，见 pom.xml#L293-L299），用于 gRPC 通信及 etcd 客户端；
• com.azure:azure-sdk-bom（版本 1.2.10，见 pom.xml#L721-L727），统一 Azure 系列 SDK；
• org.springframework.cloud:spring-cloud-dependencies（版本 2021.0.3，见 pom.xml#L741-L747）。

这种"官方 BOM + 自定义版本属性"的分层结构，既保证了与上游框架版本对齐，又让 DolphinScheduler 特有的依赖（如 DolphinScheduler 自身模块、插件体系）有独立的版本入口。值得注意的是，根 pom.xml#L66 中定义的spring.boot.version为 2.6.1，而 BOM 将其覆盖为 2.7.3，这正是 BOM 在子模块层级生效、优先级更高的体现。

传递依赖的排除与安全治理

第三方依赖往往自带大量传递依赖，直接使用会产生冲突甚至安全风险。dolphinscheduler-bom在声明依赖时做了大量<exclusions>处理，这也是它作为"版本治理中枢"的重要职责。典型例子：

• ZooKeeper：排除slf4j-log4j12（避免日志实现冲突）、io.netty:netty（避免与新版 Netty 冲突）、spotbugs-annotations，见 pom.xml#L212-L231；
• cron-utils：排除javassist，见 pom.xml#L194-L204；
• hadoop-common：排除slf4j-log4j12、jersey-json、junit、servlet-api、slf4j-reload4j等，见 pom.xml#L478-L505；
• spark-hive_2.12：排除commons-httpclient、httpclient及旧版 Jackson（jackson-core-asl、jackson-mapper-asl），见 pom.xml#L813-L835。

在安全治理方面，代码注释明确说明了两个 CVE 相关决策（见 pom.xml#L527-L538）：

• htrace-core4的 scope 被设为provided，使其不会随 hadoop-* 传递依赖进入产物；
• 用org.apache.hbase.thirdparty:hbase-noop-htrace（版本4.1.1）替换htrace-core以规避已知 CVE。

此外，BOM 还通过<scope>将大量仅用于测试或运行期外部的依赖做了限定，例如：数据库驱动（mysql-connector-java、ojdbc8、ngdbc、redshift-jdbc42等）多声明为testscope（见 pom.xml#L392-L429），Testcontainers 系列（testcontainers、mysql、postgresql、minio）统一为test（见 pom.xml#L944-L971），system-lambda也仅用于测试。这种 scope 治理能显著减小最终发行包的体积并降低运行时依赖面。

通过 Maven Profile 切换 ZooKeeper 版本

BOM 文件末尾定义了两个互斥的 Maven Profile，用于切换 ZooKeeper 及其客户端 Curator 的版本组合（见 pom.xml#L992-L1014）：

• zk-3.8（默认激活，activeByDefault=true）：zookeeper.version为3.8.0，curator.version为5.3.0；
• zk-3.4：通过-Dzk-3.4属性激活，zookeeper.version为3.4.14，curator.version为4.3.0。

这两个属性在 BOM 的<dependencyManagement>中被zookeeper与curator-*系列构件引用（见 pom.xml#L212-L279）。该设计服务于不同 ZooKeeper 集群环境的兼容性需求：当你的注册中心运行在 ZooKeeper 3.4 等旧版本上时，可以显式启用zk-3.4Profile 构建，让整个依赖树切换到对应版本的客户端。

这一机制的实际消费方是 dolphinscheduler-registry-zookeeper 模块——它通过importBOM 后直接声明zookeeper、curator-framework、curator-client、curator-recipes、curator-test等无版本依赖（见该模块 pom.xml#L60-L93），由 BOM 统一决定具体版本。

如何验证 BOM 是否生效

导入 BOM 后，可用以下命令验证依赖版本解析结果（假设在仓库根目录执行）：

# 查看某模块依赖树，确认 guava 等依赖版本来自 BOM ./mvnw dependency:tree -pl dolphinscheduler-common # 查看被管理的依赖及其版本 ./mvnw help:effective-pom -pl dolphinscheduler-common

dependency:tree会输出每个依赖的最终解析版本；若版本与 BOM 定义不一致，多半是某个模块在自己的dependencyManagement或<dependencies>中显式覆盖了版本，可结合help:effective-pom生成的"有效 POM"核对最终的版本裁决结果。

实践要点小结

围绕 dolphinscheduler-bom/README.md 及其实现，可以总结出以下可直接迁移到自身工程的实践要点：

1. 统一入口：用独立的 BOM 模块集中管理第三方依赖版本，业务模块一律无版本声明，升级只需改 BOM 一处；
2. 分层嵌套：生态成熟的框架直接导入官方 BOM，自有或定制依赖才手写版本，降低维护成本；
3. 覆盖有度：允许下游按"就近优先"覆盖版本，但应作为特例并做回归验证；
4. 主动排雷：在 BOM 层统一处理日志实现冲突、旧版 Jackson 等历史包袱，并对 CVE 依赖做替换或 scope 收窄；
5. 环境适配：用 Profile 表达对不同基础组件版本（如 ZooKeeper 3.8 / 3.4）的兼容组合，构建期按需切换。

若你正在为 DolphinScheduler 开发自定义数据源、任务或告警插件，按本文方式导入dolphinscheduler-bom，即可与官方模块共享同一套经过验证的依赖版本基线，省去手工对齐版本号的繁琐工作。

• 任务调度
• 大数据
• 后端
• 前端