While initially this may seem a trivial problem as requirements grow the complexity of the solutions will also. Here are some of the requirements you might have to tackle:
- Overriding default properties
- Dealing with properties that need to kept secret to the development team e.g. production passwords
- Properties that need to be changed dynamically (tuned) while the app is running e.g. cache configuration
- The addition of new environments after the original artifact has been built
Not the Solution
- Inefficient - the simple fact that do you have to rebuild the artifact for each environment is time consuming and involves repetition of effort
- Risky - After testing your artifact in your test environment you are then going to deploy a different artefact that was never tested to production
- Unnecessary Builds - If the properties change after you build the artifact - you need to build it again!
- Hard to diagnose problems - did some deploy the test war to production by accident? Get used to having to crack open jar's and war's to check the config.
- Not compatible with Maven repositories - Maven repositories work best with one version of an artifact per version number - e.g. there's only one Apache commons-collections 3.2.1. An artefact per environment breaks this.
So what to do instead? Generally the best way to go is to externalise your properties from the artefact and then have it choose the correct properties at runtime. This is too general an area for one prescriptive approach but hopefully this article has ruled out building an artifact per environment.