Another approachf for this: We use maven profiles. You can define your props within each profile. (e.g. "dev", "prod1", "prod2" etc.) "dev" is the default profile. Advantage of this is, that you can define properties for maven plugins within each profile, too. E.g. we define the "doCheck" and "doUpdate" props of the buildnumber- maven-plugin within each profile. With this, we ensure all resources are comitted before we create a production war file.
Robert Am 11.08.2009 um 15:33 schrieb Bruno Melloni: > We use a variation of this approach in most of our projects, by > taking advantage of the PropertyOverrideConfigurerÿÿs behavior: > > - This configurer wasÿÿ designed so that you can have > multiple PropertyOverrideConfigurer that load different files, even > if they have the same properties.ÿ If a variable is defined/loaded > multiple times, the definition from the last configurer is the one > used. > - So, we define identical properties files for each > environment, and load them in order of finality (PROD first, DEV > last). > - We use ignoreResourceNotFound = ÿÿtruÿÿ so that > missing properties files donÿÿt cause problems. > > The result is: > > - In version control and DEV environments we have all of > the properties files, allowing us to work and prepare them for all > environmentsÿÿ But only the DEV configuration gets usedÿÿ because > its property configurer is the last one. > - When deploying to other environments we simply doÿÿt > deploy unnecessary properties filesÿÿ For example, in PROD we only > deploy the PROD properties filÿÿÂ The missing files are ignored, > and the app behaves as PROÿÿâÿ with no fuss. > - We never have to modify the app, context or even property > files during deployment. > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
