Maven依赖管理：dependencies、dependencyManagement与BOM分别改变了什么

父POM已经管理了一个库的版本子模块里却仍然没有这个依赖把配置移到父POM的dependencies子模块没写依赖也出现了它。这两种结果都可能是正确的关键是先分清声明要用什么和管理用了以后采用什么配置是两件事。这次用Maven 3.9.12、JDK 21.0.2做了一个最小模型实验。只保留父POM的dependencyManagement时子项目的有效POM没有直接依赖子项目再声明同一个库版本才补成1.4。整个过程不需要Spring项目也不需要用一个大型依赖树掩盖配置关系。2026-11-02修订补充可复现的有效POM对照纠正scope与打包的关系并明确BOM导入和父POM继承的边界。同一个坐标先看它出现在哪里dependencies里的声明参与构建项目的依赖关系。这个声明可以来自当前POM也可以从父POM继承此外还可能通过传递依赖引入其他库。dependencyManagement提供的是依赖配置管理。它不会单凭一条管理记录就给当前项目增加依赖但会影响匹配依赖的版本、scope等信息也能控制依赖图中匹配的传递依赖版本。把它叫“版本清单”方便入门不能理解成它只是一段不参与解析的文档。创建两个目录先保存parent-managed/pom.xmlproject xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdexample.fixture/groupId artifactIdparent-managed/artifactId version1.0/version packagingpom/packaging dependencyManagement dependencies dependency groupIdexample.fixture/groupId artifactIddemo-lib/artifactId version1.4/version /dependency /dependencies /dependencyManagement /project再保存managed-use/pom.xmlproject xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion parent groupIdexample.fixture/groupId artifactIdparent-managed/artifactId version1.0/version relativePath../parent-managed/pom.xml/relativePath /parent artifactIdmanaged-use/artifactId packagingpom/packaging dependencies dependency groupIdexample.fixture/groupId artifactIddemo-lib/artifactId /dependency /dependencies /project在两目录的上一级执行$effectiveFile Join-Path $PWD effective-managed.xml mvn -B -ntp -f managed-use/pom.xml org.apache.maven.plugins:maven-help-plugin:3.5.2:effective-pom -Doutput$effectiveFileeffective-pom把继承、管理等处理后的项目模型写成XML。Help Plugin文档说明了输出参数这里固定插件版本避免命令简写的插件解析随环境变化。本次生成的顶层dependencies中example.fixture:demo-lib的版本是1.4。然后分别改变一处配置得到以下结果配置子项目有效POM中的直接依赖父POM只管理版本子项目没有声明依赖没有demo-lib父POM管理1.4子项目声明demo-lib并省略版本demo-lib:1.4父POM在普通dependencies声明demo-lib:1.4子项目不再声明继承demo-lib:1.4父POM管理1.4子项目在直接依赖上明确写4.0demo-lib:4.0这里的坐标是人工示例实验观察的是项目模型没有解析这个库的JAR也没有编译业务代码。effective-pom成功不代表对应版本一定存在更不代表它可以与项目其他库一起正常运行。最后一行也说明dependencyManagement不是无法绕过的锁。直接依赖显式写出的版本可以覆盖管理值。团队若要禁止越界版本需要另外的规则和检查不能只看父POM里写过一个版本。图1分别看有没有直接依赖、采用哪个版本。管理不会自动注入直接声明也可以覆盖管理版本。scope控制可见性不能直接等同于“打进JAR”先修正一个常见说法普通Maven JAR项目执行打包并不会自动把所有compile依赖的类塞进生成的JAR。依赖的classpath范围与最终如何组装产物需要分开看。scope主代码编译测试编译/执行应用运行classpathcompile默认包含包含包含provided包含包含不由这项依赖加入runtime不包含包含包含test不包含包含不包含provided常用于明确由运行环境提供的API前提是你的部署环境确实提供它。WAR、Spring Boot重打包、Shade等组装方式对依赖的处理还各有规则不能仅凭scope就断言某个最终文件里一定有或一定没有某个JAR。system依赖本地路径通常会增加可移植性问题import则用于导入管理模型不属于普通运行classpath。范围定义见Maven依赖机制说明。BOM导入的是哪一部分项目已经有父POM但又希望使用另一套依赖版本管理可以在dependencyManagement中导入BOMtypepomscopeimport。它没有给项目增加第二个父POM。为了把导入边界看清下面的demo-bom/pom.xml故意多放了一个普通依赖、一个属性标记和一个插件管理标记。它们只用于观察哪些内容会进入消费者不是建议把BOM设计成这样project xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdexample.fixture/groupId artifactIddemo-bom/artifactId version1.0/version packagingpom/packaging properties demo.version2.0/demo.version bom.markernot-inherited/bom.marker /properties dependencyManagement dependencies dependency groupIdexample.fixture/groupId artifactIddemo-lib/artifactId version${demo.version}/version /dependency /dependencies /dependencyManagement dependencies dependency groupIdexample.fixture/groupId artifactIdbom-only-dep/artifactId version9.9/version /dependency /dependencies build pluginManagement plugins plugin groupIdexample.fixture/groupId artifactIdbom-only-plugin/artifactId version9.9/version /plugin /plugins /pluginManagement /build /project消费者保存为import-use/pom.xmlproject xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdexample.fixture/groupId artifactIdimport-use/artifactId version1.0/version packagingpom/packaging dependencyManagement dependencies dependency groupIdexample.fixture/groupId artifactIddemo-bom/artifactId version1.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdexample.fixture/groupId artifactIddemo-lib/artifactId /dependency /dependencies /project将这个自建BOM安装到示例专用仓库再生成消费者的有效POM$demoRepository Join-Path $PWD .demo-repository $effectiveBomFile Join-Path $PWD effective-import.xml mvn -B -ntp -Dmaven.repo.local$demoRepository -f demo-bom/pom.xml org.apache.maven.plugins:maven-install-plugin:3.1.3:install mvn -B -ntp -Dmaven.repo.local$demoRepository -f import-use/pom.xml org.apache.maven.plugins:maven-help-plugin:3.5.2:effective-pom -Doutput$effectiveBomFile第一次执行需要下载官方插件。这里安装的只是示例自己的POM没有向远程仓库发布任何东西。查看effective-import.xml本次结果是顶层直接依赖只有demo-lib:2.0BOM里的${demo.version}已用于求出这个版本。bom-only-dep没有作为消费者的直接依赖出现。消费者没有继承bom.marker属性也没有导入bom-only-plugin的插件管理。删除消费者的普通dependencies以后导入的管理记录仍在顶层直接依赖为空。导入不是整份POM继承。它引入目标的依赖管理内容不会顺便拿到目标的构建配置即便目标BOM使用属性组织版本也不能把导入理解成那些属性都成为了消费者自己的属性。官方Importing Dependencies示例展示了这项机制。本次另一个对照是在消费者自己的dependencyManagement里明确管理demo-lib:3.0同时保留BOM导入最终直接依赖采用3.0。需要覆盖BOM版本时把覆盖写在消费者自己的管理项中比依赖对方POM内部的属性名更容易审查。图2import导入BOM的依赖管理内容不把普通依赖、属性标记或插件管理一起继承给消费者。依赖还不对时检查匹配和实际路径没有父管理、没有BOM又在直接依赖中省略版本本次mvn validate就报出dependencies.dependency.version for example.fixture:demo-lib:jar is missing.管理项还需要匹配依赖身份。通常只写groupId和artifactId就够是因为默认type为jar、classifier为空完整匹配还包括type和classifier。本次只管理默认jar把使用处改成typewar并省略版本得到的仍是缺少版本错误不会因为G、A相同就自动套用。如果问题来自传递依赖先确认是谁把它带进来。Maven通常按更近的路径选择版本同深度再看先声明者匹配的依赖管理还能影响传递版本。exclusions排除的是某条依赖路径下面的传递依赖并不是从父POM继承的整个直接依赖列表中任意删除一项。另一路仍然引入同一库时它也可能继续留在依赖图中。因此排查时先用有效POM确认继承与管理结果再用dependency:tree观察真实解析路径后者需要对应构件可解析不能拿本文的人工坐标直接当作真实库。BOM能集中表达发布者选择的一组版本Maven本身不会替发布者证明这些版本已经兼容。升级后仍要跑应用的构建和关键测试。把依赖管理做好解决的是版本选择有出处、覆盖可追踪运行兼容性还要由实际验证回答。接着可以看父POM、聚合POM与BOM的关系同样写着packagingpom三者建立关系的方式并不相同。