Maven项目：运行时替换依赖JAR属性占位符的方案咨询

针对你遇到的这个依赖JAR属性占位符动态替换的问题，结合你的场景（数十个项目依赖通用JAR、外部框架无法解析占位符、不能解压WAR修改文件），我整理了几个可行的方案，从优化你想到的思路到Spring原生机制再到运行时动态资源处理，供你参考：

方案1：优化你提出的独立属性JAR思路 #

你提到把属性放到B依赖的独立JAR里，这个方向是对的，不过可以优化掉解压操作，利用Spring的属性加载优先级来实现：

• 先做拆分：给B依赖一个通用的属性JAR空壳（比如B-props-api.jar），里面只定义属性的占位符模板；然后每个业务项目（比如A）创建自己的专属属性JAR（A-props.jar），里面写好对应占位符的具体值
• 在Spring Boot启动时，让项目专属的属性JAR优先级高于B的属性JAR：通过自定义ApplicationContextInitializer，把项目专属属性JAR中的配置加载为高优先级的PropertySource，这样Spring在解析B中的propsB.properties时，会自动用专属值替换占位符
• 优势：不用解压任何JAR，每个项目只需要维护自己的属性JAR，B可以保持完全通用，适配数十个依赖项目的不同需求

方案2：Spring Boot原生占位符解析器（适合Spring管控的属性） #

如果不想拆分额外的JAR，可以直接在A项目中通过Spring的原生机制覆盖解析：

• 创建一个配置类，使用PropertySourcesPlaceholderConfigurer来指定额外的属性源，提供占位符的替换值：

@Configuration
public class CustomPropertyResolverConfig {
    @Bean
    public static PropertySourcesPlaceholderConfigurer propertyConfigurer() {
        PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer();
        // 加载A项目专属的属性文件，里面写占位符对应的具体值
        configurer.setLocations(new ClassPathResource("application-A-custom.properties"));
        // 设置最高优先级，确保先解析占位符再加载B的属性
        configurer.setOrder(Ordered.HIGHEST_PRECEDENCE);
        return configurer;
    }
}

• 在application-A-custom.properties中写入：

property.set.by.A=your-project-A-specific-value

• 注意：这个方案只适用于Spring能管控的属性，如果外部框架是直接读取类路径下的propsB.properties文件而不经过Spring解析，那这个方案就不适用了，得用下面的方案3

方案3：运行时动态修改类路径资源（适配外部框架） #

如果外部框架直接读取B JAR中的属性文件，那可以通过自定义资源加载逻辑，在内存中动态替换占位符，不需要修改物理文件：

• 先实现一个包装类PlaceholderResolvingResource，它会在读取资源内容时自动替换占位符：

public class PlaceholderResolvingResource extends Resource {
    private final Resource delegateResource;
    private final Properties placeholderValues;

    public PlaceholderResolvingResource(Resource delegate, Properties values) {
        this.delegateResource = delegate;
        this.placeholderValues = values;
    }

    @Override
    public InputStream getInputStream() throws IOException {
        // 读取原属性文件内容
        String rawContent = new String(delegateResource.getInputStream().readAllBytes(), StandardCharsets.UTF_8);
        // 替换所有{xxx}格式的占位符
        for (String key : placeholderValues.stringPropertyNames()) {
            rawContent = rawContent.replace("{" + key + "}", placeholderValues.getProperty(key));
        }
        // 返回替换后的内容流
        return new ByteArrayInputStream(rawContent.getBytes(StandardCharsets.UTF_8));
    }

    // 其他Resource接口方法直接委托给原资源
    @Override
    public boolean exists() {
        return delegateResource.exists();
    }

    @Override
    public String getDescription() {
        return delegateResource.getDescription();
    }

    // 省略其他方法的实现，都直接调用delegateResource的对应方法即可
}

• 然后在Spring Boot启动时，替换默认的资源加载器，让它优先使用我们的包装类处理B的属性文件：

@SpringBootApplication
public class AApplication {
    public static void main(String[] args) {
        // 加载项目专属的占位符值
        Properties customValues = new Properties();
        try {
            customValues.load(new ClassPathResource("placeholder-values.properties").getInputStream());
        } catch (IOException e) {
            throw new RuntimeException("Failed to load placeholder values", e);
        }

        // 自定义资源加载器
        ResourceLoader customLoader = new DefaultResourceLoader() {
            @Override
            protected Resource getResourceByPath(String path) {
                Resource originalResource = super.getResourceByPath(path);
                // 判断是否是B JAR中的目标属性文件
                if (path.contains("propsB.properties") && originalResource instanceof ClassPathResource) {
                    return new PlaceholderResolvingResource(originalResource, customValues);
                }
                return originalResource;
            }
        };

        // 用自定义资源加载器启动Spring应用
        new SpringApplicationBuilder(AApplication.class)
                .resourceLoader(customLoader)
                .run(args);
    }
}

• 这个方案的核心是在内存中修改资源内容，不管是Spring还是外部框架，读取类路径下的属性文件时，拿到的都是已经替换好的内容，完全不需要修改物理的JAR/WAR文件

方案4：构建时替换占位符（适合独立构建的项目） #

如果每个项目都是独立构建部署的，也可以在Maven/Gradle构建阶段就完成占位符替换，不需要运行时逻辑：

• 在A项目的pom.xml中配置Maven依赖插件和资源过滤：

<build>
    <resources>
        <resource>
            <directory>${project.build.directory}/dependency</directory>
            <includes>
                <include>**/propsB.properties</include>
            </includes>
            <filtering>true</filtering>
        </resource>
    </resources>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <executions>
                <execution>
                    <id>unpack-b-props</id>
                    <phase>process-resources</phase>
                    <goals>
                        <goal>unpack-dependencies</goal>
                    </goals>
                    <configuration>
                        <includeGroupIds>mygroup</includeGroupIds>
                        <includeArtifactIds>B</includeArtifactIds>
                        <includes>**/propsB.properties</includes>
                        <outputDirectory>${project.build.directory}/dependency</outputDirectory>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

• 然后在src/main/filters/filter.properties中写入：

property.set.by.A=your-project-A-value

• Maven会在构建时自动解压B JAR中的属性文件，替换占位符后再打包到最终的WAR中，这样部署后的WAR里的属性文件已经是替换好的内容

方案选择建议 #

• 如果外部框架需要直接读取属性文件：优先选方案3
• 如果所有属性都通过Spring管理：选方案2最简洁
• 如果需要数十个项目共享B且各自维护属性：选方案1扩展性最好
• 如果每个项目独立构建：选方案4最省心

内容的提问来源于stack exchange，提问作者yoplay one