Different Property Sets in Maven

Problem

Don't separating custom properties from code have side effects. You will have to customize a properties file according a current purpose, without loosing other property constellations for a specific build (e.g. builds for testing, builds for demo servers, etc.). These may also contain sensible customer related infos like passwords.

Keeping all those parameter files separate from code is a good idea but results in a backup-old/copy-new/renaming-new scenario. This is not convenient for a lazy developer and even my end in a not intended SVN commit of such files.

Best way IMHO is to separate property files containing changing (developer setup URLs) and sensible information (passwords) from the project's working copy itself. Using Maven you can do this with a little configuration trick. See next section how it works out.

Best Practice

For run-time configuration mechanisms, see also BestPracticeUserHomeDirConfig.

Explanation

Use two different profiles one containing a default set of example properties and another one using an external filter file. The file has the syntax build-${env}.properties and has to lay in the ${user.home} directory. The ${env} property can be set to arbitrary values ( dev per default).

Pom.xml Content

   <profiles>
      <profile>
         <id>env-example</id>
         <activation>
            <activeByDefault>true</activeByDefault>
         </activation>
         <properties>
            <!--
               EXAMPLE CONFIG PROPERTIES FOLLOW. 
               TO SEPARATE CONFIGURATION FROM PROJECT, COPY build-example.properties to 
               
                  ${user.home}/build.properties
                  
               CUSTOMIZE PROPERTIES AND TRIGGER MAVEN BUILD WITH `mvn install -Denv=dev'.
             -->
            <sps.external.dcp.operation.url>http://localhost:8080/52n-sps-webapp/sps</sps.external.dcp.operation.url>
            <sps.external.admin.extension.url>http://localhost:8080/52n-sps-webapp/admin</sps.external.admin.extension.url>
            
            <config.log4j.logger.level>DEBUG</config.log4j.logger.level>
            <config.log4j.logger.level.client>DEBUG</config.log4j.logger.level.client>
            <config.log4j.logger.level.server>DEBUG</config.log4j.logger.level.server>
            <config.log4j.consoleappender.level>DEBUG</config.log4j.consoleappender.level>
            <config.log4j.fileappender.level>WARN</config.log4j.fileappender.level>
         </properties>
      </profile>
      <profile>
         <id>env-dev</id>
         <properties>
            <env>dev</env>
            <!-- externalize build parameters for productive environment -->
            <local.configfile>${user.home}/sps-build-${env}.properties</local.configfile>
         </properties>
         <build>
            <filters>
               <filter>${local.configfile}</filter>
            </filters>
         </build>
      </profile>
   </profiles>

Commandline Call

We have three possibilities to build the project:

Example Parameters

mvn install (uses properties from default profile)

Custom Parameters

mvn install -Penv-dev (uses a filter file laying at ${user.home}/sps-build-dev.properties)

Arbitrary Parameters

mvn install -Penv-dev -Denv=other_custom_demo_server_deploy_config (uses a filter file laying at ${user.home}/sps-build-other_custom_demo_server_deploy_config.properties)

Notes

Change your local.configfile pattern to refer to the project you are about to work with (e.g. sps_v2-build-${env}.properties). Then you can have all the build files laying together in your system.