On 1/22/07, James Carman <[EMAIL PROTECTED]> wrote:
"Using the server admin lets you take the same web application and deploy it *unmodified* in different environments where you really want to connect to different services (such as a testing server, a staging server, and a production server)." If you make your build system smart enough, you can have it generate your context.xml file with the correct settings (Velocity comes in handy here) depending upon your targeted environment (test vs. prod). I usually do this using a build.properties file in Ant. In order to change your targeted environment, all you have to do is change the build.properties file and that's it.
Sure, you can do a lot more work in your build script if you want to :-). But, I have also seen lots of big shops that are totally allergic to testing one version of an app but then needing to build it again before deployment. They want to be sure the bits they test are *exactly* the bits that are actually deployed. For this scenario, having an ability to configure resources externally is extremely valuable. Come to think of it, this is very similar to the attitude we have in Apache projects, where a proposed release needs to have the actual bits we are voting on (versus a promise to build from a particular SVN tag or revision number later on). Craig
