Ok, that's fine, but now instead of releasing a simple .war file for someone to drop into a servlet container, you are making them run an ant build in order to deploy your app. Not my idea of portability, but you can do what works for you.
For development purposes, you can easily do a filter copy of the context.xml file so you provide build time paths and put those in <Property> or <Environment> entries in the context.xml during the filter copy. This combines the best of all worlds. You have a simple development environment to work with and you can easily deploy a .war file to a server without requiring the ant build.
Jake
At 05:30 PM 3/29/2003 +0100, you wrote:
Hi Jacob,
I think the decision about where the locally stored data should go should be done at build time. I'd suggest to use two directories within the ant tree structure:
/web/.... // stores the static data independent of location /web-production/ // stores the config data which should be used in production /web-preproduction/ // stores the config data which should be used in pre-production mode (testenvironment) /web-development // stores the config data which should be used in development
context.xml could store the entry path of the locallay stored data /web-development/META-INF/context.xml // stores entry point and urls for development /web-preproduction/META-INF/context.xml // stores entry point and urls for pre-production /web-production/META-INF/context.xml // stores entry point and urls for production
when I build I could say ant -Dtarget=production ant -Dtarget=preproduction ant -Dtarget=development
and have the ant task copy the proper configuration files. This way I could easily test in preproduction and then deploy the same webapp, with only minor context configuration changes (and thus minimized error probability).
What do you think about this approach?
Johannes
