Great question—this is a super common scenario when building apps that need to behave differently between local development and production deployment. Let’s break this down for you step by step.

1. Setting Different File Paths for Dev vs Deployment #

The core idea here is to use environment-specific configuration so your app automatically picks the right path based on its runtime context. Here are two practical approaches:

Using Framework Configuration Profiles #

If you’re working with a framework like Spring Boot, profile-specific config files are your best bet:

• Create application-dev.yml (for local development) and application-prod.yml (for deployment) in your resources folder.
• Define your path property in each file:

  # application-dev.yml
  config.file.path: src/main/resources/config.xml
  

  # application-prod.yml
  config.file.path: /opt/myapp/config/config.xml
  

• Inject this property into your code wherever you need to load the file:

  @Value("${config.file.path}")
  private String configFilePath;
  
  // Use configFilePath to read your XML file
  

• Activate the right profile when running: use spring.profiles.active=dev locally, and switch to prod for production deployments.

Using Build Tool Resource Filtering #

If you’re using Maven or Gradle, you can have the build tool replace path placeholders based on the build profile:

• For Maven:
  1. Add profiles to your pom.xml to define environment-specific paths:

     <profiles>
       <profile>
         <id>dev</id>
         <properties>
           <config.path>src/main/resources/config.xml</config.path>
         </properties>
       </profile>
       <profile>
         <id>prod</id>
         <properties>
           <config.path>/opt/myapp/config/config.xml</config.path>
         </properties>
       </profile>
     </profiles>
     

  2. Enable resource filtering so Maven replaces placeholders in your config files:

     <build>
       <resources>
         <resource>
           <directory>src/main/resources</directory>
           <filtering>true</filtering>
         </resource>
       </resources>
     </build>
     

  3. Use the placeholder in your app’s config file (e.g., application.properties):

     config.file.path=${config.path}
     

• Build with the desired profile: run mvn clean install -Pprod for production, or just mvn clean install (if dev is set as default) for local work.

2. Switching config.xml Path During Build #

Building on the above, here’s how to specifically handle your config.xml scenario:

Option 1: Externalize config.xml for Production #

• In development, keep config.xml in src/main/resources and use the dev profile to point to this path.
• For deployment, don’t package config.xml into your JAR/WAR—instead, place it in an external directory (like /opt/myapp/config) and use the prod profile to target that external path.
• To exclude config.xml from the production build in Maven, add this to your prod profile:

  <profile>
    <id>prod</id>
    <build>
      <resources>
        <resource>
          <directory>src/main/resources</directory>
          <excludes>
            <exclude>config.xml</exclude>
          </excludes>
        </resource>
      </resources>
    </build>
  </profile>
  

Option 2: Replace Path Placeholders in Code (Less Recommended) #

If you need hardcoded paths (not ideal, but sometimes necessary), use a build plugin to replace placeholders during compilation:

• Add a placeholder in your code:

  private static final String CONFIG_PATH = "${config.path}";
  

• Use the Maven Replacer Plugin to swap the placeholder during the build phase:

  <build>
    <plugins>
      <plugin>
        <groupId>com.google.code.maven-replacer-plugin</groupId>
        <artifactId>replacer</artifactId>
        <version>1.5.3</version>
        <executions>
          <execution>
            <phase>prepare-package</phase>
            <goals>
              <goal>replace</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <files>
            <file>target/classes/com/yourpackage/YourConfigClass.class</file>
          </files>
          <replacements>
            <replacement>
              <token>${config.path}</token>
              <value>${config.path}</value>
            </replacement>
          </replacements>
        </configuration>
      </plugin>
    </plugins>
  </build>
  

• Note: Stick to profile-based config if you can—it’s far more flexible and easier to maintain.

The biggest takeaway is to keep environment-specific settings separate from your core code. This way, switching between dev and deployment environments requires zero code changes, just a profile switch or build flag.

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