What are the pros and cons for this?

I feel more comfortable having everything in the war file, because then if I 
change one of the properties files all I have to do is rebuild, check the war 
file in to subversion, then our release management people check it out on the 
appropriate layer.  If the properties file was external then that's another 
file for them to have to deal with.

It seems less error prone when the war file is completely self contained.


Michael McCallum wrote:
I would highly recommend you externalise environmental configuration such that 
you don't need to rebuild any artifacts when moving them from one environment 
to another.

On Fri, 07 Nov 2008 08:46:31 Hayward Lam wrote:
Hi all,

We have in-house maven projects. The build requires environment specific
property replacement (i.e. dev, qa and prod) and we set up profiles for
them. When the project has been tested and is ready for release, we can
deploy the artifacts (dev, qa and prod) to our internal maven
repository.
My questions are:

1)      Is there some sort of release management tool that can automate
this process?

2)      We use Hudson for continuous integration. The configuration will
be based on each environment only (i.e. -P env-dev). So, each build will
have its own build number. Is there some consolidated way to do this?
i.e. same build number for dev, qa and prod.

3)      What is the practice that works for you?

Thanks






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to