在多模块 Maven 项目中，子模块（如 common-module）默认不会自动发布到本地或远程仓库；若其他独立项目需依赖它，必须先通过 mvn install 安装到本地仓库，或通过 mvn deploy 发布至共享远程仓库。
在多模块 maven 项目中，子模块（如 common-module）默认不会自动发布到本地或远程仓库；若其他独立项目需依赖它，必须先通过 `mvn install` 安装到本地仓库，或通过 `mvn deploy` 发布至共享远程仓库。
当你构建一个典型的多模块 Maven 项目（例如父项目 customer 下包含 common-module 和 service-module），Maven 仅在当前构建上下文内解析模块间依赖（即 service-module 可直接依赖 common-module，因为它们同属一个 reactor 构建）。但一旦该模块需要被外部项目（如独立的 PROJECT 2）引用，Maven 就不再识别其“模块身份”，而将其视为普通第三方依赖——此时必须确保该 artifact 已存在于 Maven 仓库中。
✅ 正确做法：两步走策略
1. 本地开发阶段：使用 mvn install
在 customer 项目根目录执行：
mvn clean install
该命令会：
- 按模块依赖顺序编译、测试并安装所有子模块（包括 common-module）；
- 将生成的 com.test:common-module:0.0.2-SNAPSHOT.jar 及其 POM 安装到本地 Maven 仓库（通常是 ~/.m2/repository/com/test/common-module/0.0.2-SNAPSHOT/）；
- 此后，在 PROJECT 2 中声明如下依赖即可成功解析：
<dependency><groupid>com.test</groupid><artifactid>common-module</artifactid><version>0.0.2-SNAPSHOT</version></dependency>
⚠️ 注意：mvn install 不会上传到远程仓库，仅限本机有效；若更换开发机或 CI 环境，需重新执行。
2. 团队/生产环境：使用 mvn deploy + 远程仓库
为支持跨机器协作，需配置 distributionManagement 并部署至私有仓库（如 Nexus、Artifactory 或 GitHub Packages）：
在 customer/pom.xml 中添加：
<distributionmanagement><repository><id>internal-releases</id><url>https://nexus.example.com/repository/maven-releases/</url></repository><snapshotrepository><id>internal-snapshots</id><url>https://nexus.example.com/repository/maven-snapshots/</url></snapshotrepository></distributionmanagement>
然后执行：
mvn clean deploy
确保 PROJECT 2 的 settings.xml 或 pom.xml 已配置对应
? 补充说明：为什么报错 Could not find artifact ... customer:pom？
错误信息中出现 com.test:common-module:jar:customer:pom:0.0.2-SNAPSHOT，表明 Maven 尝试按 groupId:artifactId:packaging:classifier:version 解析时，误将父项目 customer 当作 classifier（因继承关系未被外部项目感知），本质仍是 artifact 缺失导致的连锁失败——根源不在继承本身，而在依赖未发布。
✅ 总结
- ✅ 多模块项目的子模块对外部项目不可见，必须显式安装或部署；
- ✅ mvn install 是本地验证首选，mvn deploy 是团队协作必需；
- ✅ 确保版本号（尤其是 SNAPSHOT）与依赖声明严格一致；
- ✅ 避免在 PROJECT 2 中尝试用
引用父 POM——这仅适用于父子模块共存场景，不适用于跨项目引用。
遵循以上流程，即可彻底解决跨项目引用多模块子模块时的依赖解析失败问题。
