Each environment identifies itself and your app uses that info to connect to the right properties at runtime.
________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -----Original Message----- From: Jon Paynter [mailto:[email protected]] Sent: Tuesday, October 05, 2010 2:08 PM To: Maven Users List Subject: Re: how to centralize configuration accross multiple modules well it was a suggestion - do what you will with it. But how would you implement this using the maven way? given the following restrictions/requirements: each environment has its own hostname and number of hosts (dev 1 host, qa 4 hosts, prod 8 hosts) each environment has a different db connection string each environment has its own set of passwords for accounts (db, unix, and tibco) each environment has its own set of port numbers fo the various processes. each environemnt has its own set of webservice urls. and all of our j2ee processes have other application specific config values Add to that, most of the config values change frequently as things evolve and change. we found its much easier to put all these values into a single file, edit one file, and run a build. Granted this was with a morass of ant scripts, but given the volume of changes, the .properties files worked quite well. On Tue, Oct 5, 2010 at 10:27 AM, Wayne Fay <[email protected]> wrote: > > For property values -- I setup a .properties file for each of our > > environments with the default being 'dev'. So for a default build, > > the > dev > > properties are used. but when its time to build for QA or > > Production, > you > > add a cmd line argument accordingly: mvn install -DenvType=QA > > IMO this is an anti-pattern for Maven usage. You should be able to > build one single artifact in say Dev and then promote that same > untouched/changed artifact through your various environments. > Otherwise the artifact that gets QA'ed is not the same artifact that > lands in Production... which defeats the purpose of QA. > > You should generally deal with these variances in the environments via > JNDI or other mechanisms available in the platform (JavaSE/JEE or > whatever container you're deploying into). > > Wayne > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
