Handling platform-specific config file values in builds

[Brad O'Hearne <br...@neurofire.com>]

Hello,

What is the generally accepted convention for handling builds where 
there are configuration files whose values are different depending upon 
the target platform being built for? For example, I may have a 
configuration file with JDBC URLs in it, and these values may be 
different depending upon whether I am building for a development 
environment, or a testing or production environment. Or, another example 
would be variations in web.xml files depending upon whether the WAR file 
will be deployed to a dev, test, or production environment. .

Advice is greatly appreciated.

Thanks,

Brad

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Handling platform-specific config file values in builds

[Brad O'Hearne <br...@neurofire.com>]

Graham,

That's great advice, and one that I've been pondering in several 
environments that I've configured over the years. One interesting thing 
about this scenario is that it actually requires discipline beyond that 
actual build process / system, but in application design as well. For 
instance, the servlet API specifies parameters to be passed to servlets 
on init, which complicates this very thing if the parameter value is 
environment-specfiic. So it really demands some forethought in 
application design to ensure that resource files and/or init values are 
late bound, rather than statically bound by config files like web.xml 
which by definition a servlet container is going to process.

This is probably why in various places in the Java SDK the use of System 
properties (which I personally really don't like, as it dominates the 
entire VM instance rather than the object instance) is the means of 
setting such variables, as it externalizes these values from the app in 
question.

Thanks for the reply Graham -- perhaps I'll blog an example of this soon.

Brad

Graham Leggett wrote:
> Brad O'Hearne wrote:
>
>> What is the generally accepted convention for handling builds where 
>> there are configuration files whose values are different depending 
>> upon the target platform being built for? For example, I may have a 
>> configuration file with JDBC URLs in it, and these values may be 
>> different depending upon whether I am building for a development 
>> environment, or a testing or production environment. Or, another 
>> example would be variations in web.xml files depending upon whether 
>> the WAR file will be deployed to a dev, test, or production 
>> environment. .
>
> I generally try to avoid this scenario, because it's inevitable at 
> some point that someone is going to put the test build into production 
> by mistake, and your test database will become live, or vice versa.
>
> Ideally installation specific config should go in an environment of 
> some kind external to your build, possibly stored in a separate 
> repository, or pointed to by environment variables.
>
> In other words, it should be as hard as possible for the wrong config 
> to go in the wrong place.
>
> Regards,
> Graham
> -- 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Handling platform-specific config file values in builds

[Graham Leggett <mi...@sharp.fm>]

Brad O'Hearne wrote:

> What is the generally accepted convention for handling builds where 
> there are configuration files whose values are different depending upon 
> the target platform being built for? For example, I may have a 
> configuration file with JDBC URLs in it, and these values may be 
> different depending upon whether I am building for a development 
> environment, or a testing or production environment. Or, another example 
> would be variations in web.xml files depending upon whether the WAR file 
> will be deployed to a dev, test, or production environment. .

I generally try to avoid this scenario, because it's inevitable at some 
point that someone is going to put the test build into production by 
mistake, and your test database will become live, or vice versa.

Ideally installation specific config should go in an environment of some 
kind external to your build, possibly stored in a separate repository, 
or pointed to by environment variables.

In other words, it should be as hard as possible for the wrong config to 
go in the wrong place.

Regards,
Graham
--