1. Maven多模块项目中的资源共享挑战
在复杂的maven多模块项目中，不同的模块可能需要共享配置文件、模板或其他非代码资源。一个常见的场景是，一个测试模块需要访问另一个模块中定义的全局配置。直接通过文件系统路径（例如./project-config/configs/application_config.yaml）来引用这些文件通常会导致以下问题：
- 路径硬编码与环境依赖： 文件路径通常是相对于项目根目录的，但在打包或部署后，这种相对路径可能不再有效，导致文件找不到错误。
- 可维护性差： 当文件位置或项目结构发生变化时，所有硬编码路径都需要手动更新。
- 不符合Maven规范： Maven推荐通过依赖和类路径来管理模块间的资源共享，而不是直接的文件系统访问。
为了避免上述问题，例如将配置文件从一个模块复制到另一个模块的src/test/resources，我们需要采用Maven推荐的资源共享机制。
2. Maven依赖机制与资源可访问性
Maven的核心优势之一是其强大的依赖管理能力。当一个模块（消费者模块）声明对另一个模块（提供者模块）的依赖时，提供者模块的编译输出（包括编译后的类文件和资源文件）都会被添加到消费者模块的类路径中。
关键点： Maven默认会将src/main/resources目录下的所有文件视为资源，并在构建过程中将其打包到JAR文件中，最终使其在运行时位于类路径上。
3. 实现跨模块资源访问的步骤
为了让project-algo模块能够访问project-config模块中的application_config.yaml文件，我们需要遵循以下两个核心步骤：
3.1 步骤一：在消费者模块中添加提供者模块的依赖
首先，在需要访问资源的模块（例如project-algo）的pom.xml文件中，添加对包含资源的模块（例如project-config）的依赖。
project-algo/pom.xml 示例：
4.0.0 com.company.project project ${project.version} project-algo jar com.company.project project-base ${project.version} com.company.project project-config ${project.version} test
scope 注意事项：
- 如果project-config中的资源仅用于project-algo的测试阶段，推荐将依赖范围设置为
test 。这样可以避免在生产环境中不必要地打包project-config。 - 如果project-config中的资源在project-algo的运行时也需要，则可以省略scope（默认为compile）。
3.2 步骤二：将配置文件置于提供者模块的src/main/resources目录
为了让application_config.yaml能够通过类加载器访问，它必须位于project-config模块的src/main/resources目录下。
文件结构调整建议：
project-config
├── pom.xml
└── src
└── main
└── resources
└── application_config.yaml如果无法移动文件（例如configs目录必须保持独立）：
如果application_config.yaml必须保留在project-config/configs/目录下，并且您希望它能作为资源被访问，您需要在project-config的pom.xml中配置Maven的资源插件，将configs目录声明为资源目录：
project-config/pom.xml 示例：
4.0.0 com.company.project project ${project.version} project-config jar src/main/resources configs **/*.yaml .
通过上述配置，project-config/configs/application_config.yaml 将会在project-config模块打包时被包含在JAR的根目录下，从而在project-algo的类路径上可用。
3.3 步骤三：通过类加载器访问资源
一旦project-config作为依赖添加到project-algo，并且application_config.yaml被正确地置于project-config的资源目录下，project-algo就可以通过类加载器来访问这个文件了。
YamlReader 修改示例：
package com.company.project.util.io;
import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.ObjectMapper; // 泛化，如果YamlReader也用于JSON
import com.fasterxml.jackson.dataformat.yaml.YAMLMapper;
import java.io.IOException;
import java.io.InputStream;
public class YamlReader {
// 假设 ConfigParent 是一个通用的父接口或类
// public interface ConfigParent {}
public static C readConfiguration(Class configClass, String yamlFileName) throws IOException {
InputStream inputStream = null;
try {
// 使用当前类的类加载器来获取资源
// 资源路径是相对于类路径根目录的
// 如果 application_config.yaml 在 src/main/resources 下，直接使用文件名
// 如果在 project-config/configs 下并通过 pom 配置为资源，也直接使用文件名
inputStream = YamlReader.class.getClassLoader().getResourceAsStream(yamlFileName);
if (inputStream == null) {
// 尝试使用线程上下文类加载器，有时在某些环境中更可靠
inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream(yamlFileName);
}
if (inputStream == null) {
throw new IOException("Resource not found on classpath: " + yamlFileName);
}
YAMLMapper mapper = new YAMLMapper();
mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);
mapper.enable(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY);
return mapper.readValue(inputStream, configClass);
} finally {
if (inputStream != null) {
inputStream.close();
}
}
}
// 示例用法（在 AlgorithmTest 中）
// public void testReadConfig() {
// try {
// MyConfig config = YamlReader.readConfiguration(MyConfig.class, "application_config.yaml");
// // 处理 config 对象
// } catch (IOException e) {
// e.printStackTrace();
// // }
// }
} 注意事项：
- 资源路径： getResourceAsStream()方法期望的路径是相对于类路径根目录的。如果application_config.yaml直接位于src/main/resources或通过配置被映射到JAR根目录，那么直接使用文件名即可。如果它位于src/main/resources/config/下，则路径应为"config/application_config.yaml"。
- 关闭流： 始终确保在使用完InputStream后将其关闭，以释放系统资源。
4. 为什么之前的尝试不奏效？
- new FileInputStream(new File("./project-config/configs/" + yamlFileName))： 这种方式是直接访问文件系统路径。它在开发环境中可能有效，因为文件实际存在于指定相对路径。但在打包成JAR或部署到其他环境时，这个相对路径很可能不再指向正确的文件，因为JAR包内部的文件不再是独立的文件系统路径。
- ModuleLayer.boot().findModule("project-config").orElseThrow(IOException::new).getResourceAsStream(yamlFileName)： ModuleLayer是Java 9引入的模块系统（JPMS）的一部分。它用于管理和加载Java模块（通常是基于module-info.java定义的模块）。Maven模块与JPMS模块不是同一个概念。在传统的Maven项目中，即使有多个模块，它们通常仍然运行在同一个“未命名模块”或“类路径”上，而不是独立的JPMS模块。因此，findModule("project-config")很可能找不到对应的JPMS模块，导致操作失败。
5. 总结与最佳实践
在Maven多模块项目中，跨模块共享资源的最佳实践是：
- 利用Maven依赖： 将包含资源的模块声明为消费者模块的依赖。
- 遵循Maven资源约定： 将需要共享的资源文件放置在提供者模块的src/main/resources目录下。如果需要自定义资源目录，通过pom.xml中的build/resources配置。
- 通过类加载器访问： 在代码中使用Class.getResourceAsStream()或ClassLoader.getResourceAsStream()来获取资源，确保资源在运行时能够被正确加载，无论应用程序如何打包或部署。
通过遵循这些原则，您可以构建出结构清晰、易于维护且部署灵活的Maven多模块项目。
