Mvn

一句话总结：Maven 的传递依赖不是靠 JAR 文件本身实现的，而是靠 .pom 文件中的元数据。如果你用 mvn install:install-file 安装一个 JAR 却没提供 POM，那它就是一座“断桥”——别人能引用你，但走不到你依赖的库。 在日常开发中，我们经常遇到这样的场景：第三方供应商给了你一个闭源 SDK，只有 .jar 文件，我们都会使用： mvn install:install-file -Dfile=your-jar.jar -DgroupId=com.yourcompany -DartifactId=your-jar -Dversion=1.0.0 -Dpackaging=jar 看起来一切正常，项目也能编译通过。但一运行就报错： java.lang.NoClassDefFoundError: com/yourcompany/yourjar/YourClass 奇怪了，你的 JAR 确实依赖它，为什么 Maven 没自动下载？答案就藏在 传递依赖（Transitive Dependencies） 的工作机制里。 什么是传递依赖？假设你的项目 A 依赖库 B，而库 B 又依赖库 C 和 D。在 Maven 中，你不需要显式声明 C 和 D，Maven 会自动把它们加入 classpath —— 这就是传递依赖。 <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>32.1.3-jre</version> </dependency> Guava 的 POM 文件中声明了对 jsr305、checker-qual 等库的依赖。当你引入 Guava 时，这些依赖会自动传递进来。但有个前提：传递依赖的信息必须存在于该构件对应的 .pom 文件中。 mvn install：自带“导航地图” 当你在一个标准 Maven 项目中运行： mvn install Maven 会：编译代码、运行测试、打包生成 target/my-app-1.0.jar；同时将项目的 pom.xml 处理后安装为 my-app-1.0.pom 到本地仓库（如 ~/.m2/repository/com/example/my-app/1.0/）；这个 .pom 文件完整保留了 块。因此，当其他项目引用 com.example:my-app:1.0 时，Maven 读取 .pom，自动解析并下载所有传递依赖。 ...