In my humble opinion, the best approach here is to have an internal and external configuration. The internal configuration contains all your defaults and will be contained in your resource folder. The external configuration is a properties file deployed with your program that gets read afterwards and overrides any defaults.

For testing, it is nice since you already have everything you need to run the program without any additional configuration. In production, you can override one or more values as you need to without rewriting the program. See below for an example on how to load the configuration:

private static Properties getConfiguration() throws IOException {
    final Properties configProperties = new Properties();

    // Attempt to read internal configuration
    InputStream configStream = null;
    try {
        configStream = Main.class.getResourceAsStream("/configuration.properties");
        if(configStream != null) {
            configProperties.load(configStream);
        }
    } finally {
        if(configStream != null) {
            configStream.close();
        }
        configStream = null;
    }

    // Attempt to read external configuration (overriding as necessary)
    try {
        final File configFile = new File("configuration.properties");
        if(configFile.isFile()) {
            configStream = new FileInputStream(configFile);

            configProperties.load(configStream);
        }
    } finally {
        if(configStream != null) {
            configStream.close();
        }
    }
    return configProperties;
}

Be sure to adjust the paths as necessary, though I personally prefer to keep the main configuration in an obvious spot both in my resources class path as well as externally.

Note that depending on the information contained in the configuration, you may want to purposefully exclude some information from your internal configuration. An example might be information to connect to a database. In such a case, when testing, you provide also the external configuration yourself that has all the missing database connection info. When you deploy, you omit the external configuration and create a new one for your client (best practice dictates that you would check for the existence of these parameters for good measure, and throw an appropriate exception if missing).

Hope that helps!

Based on my experience, it’s a normal way to keep several configuration/application properties files in the repo, but remove redundant ones during building a deliverable.

Also I would like to add that it’s better to separate those two things: application properties and application configuration.

The first one can be used for keeping a deeply internal application setup, e.g.: number of available threads, number of retries etc. The application properties file is necessary part of application. Normally it’s located in the directory <project_name>/src/main/resources.

The application configuration is more client-side thing. Usually it’s used to keep configuration which could/should be changed by customer/user. In other words, that file usually contains configuration, which related to business logic of the application. Almost always that file is required, but some applications can use an internal default configuration in order to provide high availability and not rely on a configuration file only. It’s OK to put a configuration file neither in the project root folder or into a special directory: <project_name>/conf.