使用与配置

先决定是否继承 EFC 构建配置，再选择所需层级的 BOM。依赖版本集中管理后，应用仍应只声明自身使用的运行时模块。

Parent 与 BOM 的区别

接入方式	得到的内容	应用负责的内容
`dependencyManagement` 中 `type=pom`、`scope=import`	被导入 BOM 的依赖管理	父 POM、构建属性、插件、仓库与发布设置
`<parent>` 继承基础 Parent	依赖管理、属性、构建插件、仓库和发布配置	导入所需 Component/Business BOM，声明实际依赖与应用插件
`<parent>` 继承项目 Parent	上述构建基线以及三层项目 BOM	实际依赖、应用打包，以及自身发布目标

只导入 BOM 不会导入它的普通 properties、构建插件、仓库或发布配置。名称包含 parent 的构件用作 import 时，仍只是 BOM。

应用使用基础 Parent 的片段如下，放在 modelVersion 之后：

xml

<parent>
    <groupId>com.own</groupId>
    <artifactId>springboot-dependencies-parent</artifactId>
    <version>4.1.0-SNAPSHOT</version>
    <relativePath/>
</parent>

relativePath 留空表示不通过默认的 ../pom.xml 解析父项目。父 POM 本身仍需从应用可用的仓库或本地缓存取得。

需要组件或业务时，再导入相应 BOM；可直接使用快速开始中的项目 BOM。只需要第三方版本而不需要 EFC 模块的项目，也可把导入坐标换成 springboot-dependencies-parent，避免解析 Component、Business 的 BOM。

声明实际依赖

版本管理不会自动添加依赖。应用在 dependencies 中声明具体 JAR 或 Starter 后才参与依赖解析，按用途设置 runtime、test 等 scope。

例如，MySQL 驱动作为运行时依赖：

xml

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

ClickHouse 管理的是带 all classifier 的驱动，应用声明必须匹配：

xml

<dependency>
    <groupId>com.clickhouse</groupId>
    <artifactId>clickhouse-jdbc</artifactId>
    <classifier>all</classifier>
    <scope>runtime</scope>
</dependency>

Maven 的依赖管理匹配包括 groupId、artifactId、type 和 classifier；省略 classifier 的 ClickHouse JAR 不能直接套用这一项的版本管理。

PageHelper Starter 的平台声明排除了 org.mybatis.spring.boot:mybatis-spring-boot-starter。使用时要确保已有匹配的 MyBatis 装配，例如项目的 MyBatis-Plus Boot 4 Starter；不能把 PageHelper 本身当成完整 MyBatis 接入。

构建插件

以下插件 groupId 均为 org.apache.maven.plugins，版本属性名为对应 artifactId 加 .version（例如 maven-compiler-plugin.version）。配置来自平台根 POM，经 Parent 继承；单独 import BOM 不会带入：

插件	版本	声明位置与行为
`maven-compiler-plugin`	`3.14.1`	`build/plugins`：release 为 Java 25，UTF-8，保留方法参数名
`maven-surefire-plugin`	`3.5.4`	`build/plugins`：统一测试插件版本
`maven-jar-plugin`	`3.5.0`	`pluginManagement`：管理 JAR 插件版本，JAR 项目生命周期使用它
`maven-source-plugin`	`3.3.1`	`pluginManagement`：启用后在 package 执行 `jar-no-fork` 附加源码包
`maven-javadoc-plugin`	`3.12.0`	`pluginManagement`：启用后在 verify 执行 `jar`，关闭 doclint 并启用 quiet

Compiler 显式配置了 Lombok 1.18.46 和 Spring Boot Configuration Processor 4.1.0 的注解处理路径。使用 Lombok 注解时，仍需声明 Lombok 编译依赖；额外处理器也需由应用纳入处理路径。

Source、JavaDoc 的管理配置不表示每个子项目会自动生成对应附件；需要在 build/plugins 声明后才启用相关执行。平台没有配置 spring-boot-maven-plugin 的版本或 repackage 执行。需要可运行 JAR 的应用，在已有相应 Spring Boot 依赖与启动类后显式配置：

xml

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <version>4.1.0</version>
            <executions>
                <execution>
                    <goals><goal>repackage</goal></goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

已有父 POM 管理该插件及执行时不重复添加。仅使用 BOM 的项目应在自己的构建基线中设置 Java 25、UTF-8 与编译插件，不能假定导入 BOM 就完成了构建配置。

调整版本与排查冲突

继承基础 Parent 时，可以在子 POM 中覆盖它直接引用的属性，如 guava.version。但只 import BOM 时，在应用中定义同名属性不会重新计算已导入 BOM 的内部属性。需要覆盖时，在应用自己的 dependencyManagement 中显式声明目标坐标与版本。

例如以下写法把版本值明确绑定到应用属性；示例仍使用当前基线，实际调整时修改该属性并验证兼容性：

xml

<properties>
    <app.guava.version>33.6.0-jre</app.guava.version>
</properties>
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.own</groupId>
            <artifactId>springboot-dependencies-project-parent</artifactId>
            <version>4.1.0-SNAPSHOT</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>${app.guava.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

当前 POM 的显式管理条目优先于导入 BOM 的对应条目。多个 BOM 提供同一坐标且没有显式管理时，要注意导入顺序；不要依靠随意调换 BOM 来解决兼容问题，应检查最终模型与依赖树。

对于 Netty、Jackson 等库族，不应只升级一个 JAR 就视为整族升级；检查其 BOM 管理的其他模块是否仍匹配。own.platform.version、own.component.version、own.business.version 在项目 BOM 内固定兼容组合；应用只 import 项目 BOM 时，覆盖同名本地属性不会自动改变该组合。

mvn help:effective-pom -Dverbose -Doutput=target/effective-pom.xml
mvn dependency:tree -Dverbose -Dincludes=com.google.guava:guava

前者核对模型中的最终版本、插件与来源，后者核对实际依赖路径和版本仲裁。模型解析成功并不证明源码、二进制或自动配置兼容，升级后还需在受影响应用编译和测试。

仓库配置

平台 POM 中配置了下列入口：

类型	id	地址与用途
依赖仓库	`chenxueli-public`	`https://nexus.chenxueli.cn/repository/maven-public/`，项目聚合仓库
依赖仓库	`lombok-edge`	`https://projectlombok.org/edge-releases`，Lombok edge 仓库
插件仓库	`chenxueli-public`	同一 Maven public 地址
Release 发布	`maven-chenxueli`	`https://nexus.chenxueli.cn/repository/maven-releases/`
SNAPSHOT 发布	`maven-chenxueli`	`https://nexus.chenxueli.cn/repository/maven-snapshots/`

只导入 BOM 的应用要自行配置读取仓库，示例见快速开始。首次解析 Parent 也不能依赖尚未下载的 Parent 提供仓库地址，应先在应用 POM 或 Maven settings 中配置入口。

公司镜像可通过 settings 的 mirrors/profiles 统一管理；认证信息放在 settings.xml 的 servers 中，与仓库或镜像 id 对应，不写入应用 POM。继承 Parent 会继承 distributionManagement，应用发布前需按自己的发布目标覆盖；读取依赖不需要执行 deploy。

从源码安装

首次本地接入时，在三个源码仓库的共同父目录执行，并使用同一个 Maven 本地仓库：

mvn -f own-springboot-dependencies/pom.xml -pl springboot-dependencies-parent -am clean install
mvn -f own-springboot-component/pom.xml clean install
mvn -f own-springboot-business/pom.xml clean install
mvn -f own-springboot-dependencies/pom.xml clean install

第一步安装平台聚合 POM 与基础 Parent，不解析尚未准备好的 Component/Business 统一入口。随后安装组件、业务，最后安装含项目 BOM 的完整平台。最后一步使用 install，才能让外部应用从本地仓库解析项目 BOM；verify 只验证构建，不会安装新的构件。

这些是完整源码构建命令，测试与外部服务要求以对应仓库说明为准。仅编写或阅读文档不需要执行它们。已有远端完整构件时，直接使用仓库即可。

使用与配置 ​

Parent 与 BOM 的区别 ​

声明实际依赖 ​

构建插件 ​

调整版本与排查冲突 ​

仓库配置 ​