在Java 9+模块化Maven多模块项目中，当命名模块（如service）依赖未模块化的core（作为自动模块）时，mvn test会因core未生成JAR而报“module not found”错误；本文提供无需改造core为命名模块即可修复测试执行的可靠方案。
在java 9+模块化maven多模块项目中，当命名模块（如`service`）依赖未模块化的`core`（作为自动模块）时，`mvn test`会因`core`未生成jar而报“module not found”错误；本文提供无需改造`core`为命名模块即可修复测试执行的可靠方案。
在Java平台模块系统（JPMS）中，自动模块（Automatic Module）的诞生前提是JAR文件存在且具有合法的MANIFEST.MF——即使不含module-info.class，只要JAR路径被添加到模块路径（--module-path），其文件名（去除版本号和扩展名）即成为模块名。Maven默认行为是：core模块仅在package阶段才执行maven-jar-plugin:jar生成JAR；而test阶段发生在package之前，此时core的类仅存在于target/classes/目录下，未形成JAR，因此无法被识别为自动模块，导致service模块在编译或运行测试时因requires core失败。
✅ 根本解决思路：提前生成core的JAR包，确保其在test阶段前已就绪并可被模块系统发现。
以下是在core/pom.xml中配置maven-jar-plugin的推荐方案（兼容Maven 3.5+、Java 9~21）：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.3.0</version>
<executions>
<!-- 关键：在 process-classes 阶段提前生成 JAR -->
<execution>
<id>auto-module-jar</id>
<phase>process-classes</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
<!-- 禁用默认的 package 阶段 jar 执行（避免重复打包） -->
<execution>
<id>default-jar</id>
<phase>none</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>? 为什么选
process-classes阶段？
该阶段紧随compile之后、test之前，确保core/target/core-*.jar在service模块执行编译型测试（如javac --module-path）或启动测试类加载器前已存在。同时，它早于package，不会干扰最终产物逻辑。
⚠️ 重要注意事项：
立即学习“Java免费学习笔记（深入）”；
- 此方案不影响
mvn package结果：core仍输出单个合规JAR，service正常构建。 -
IDE集成需同步配置：IntelliJ IDEA 默认不执行Maven生命周期全阶段；若直接点击“Run Test”，可能跳过
process-classes→ 建议在IDE中启用 “Delegate IDE build/run actions to Maven”（Settings → Build → Delegate IDE build/run actions to Maven），或手动触发mvn process-classes test。 - 若
core未来升级为命名模块（含module-info.java），请移除此插件配置，改用标准<modules></modules>声明，并在service中使用requires显式依赖。 - 确保
core的JAR文件名符合自动模块命名规范（如core-1.0.0.jar→ 模块名为core），避免含非法字符（如_开头、-SNAPSHOT后缀过长等），否则模块名解析可能异常。
通过这一轻量级插件重定位策略，你无需重构遗留代码、不引入额外工具链，即可让模块化与非模块化组件在Maven测试生命周期中无缝协同——这是渐进式迁移Java 9+模块系统的典型实践范式。
