maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yanko, Curtis" <>
Subject RE: how to centralize configuration accross multiple modules
Date Tue, 05 Oct 2010 18:33:45 GMT

 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 [] 
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
each environment has its own set of port numbers fo the various
each environemnt has its own set of webservice urls.
and all of our j2ee processes have other application specific config

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 <> 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:
> For additional commands, e-mail:

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:
For additional commands, e-mail:

View raw message