I'm not really sure of the best way. Right now, in src/main/webapps/META-INF/context.xml I have the docBase hardcoded to the full path to my local workspace where I'm developing from. In my previous build systems (Ant and Maven 1), as part of the war packaging system, I used Ant's XSLT task and an XSLT file targetting the context.xml file to replace those hardcoded values to the desired values (name of the war without .war for the docbase). I plan to implement this functionality as a Maven 2 plugin once I figure out how to develop a Maven 2 plugin. This approach allows me to have just one context.xml file that I actually touch.
Filtering would require me to have two files: the one with the filter tokens, and the one with those tokens replaced by my local settings to use to deploy to Tomcat for development. It would, however, prevent me from CVS'ing my local settings... -Stephen On 9/26/05, Mark Hobson <[EMAIL PROTECTED]> wrote: > On 26/09/05, Stephen Duncan <[EMAIL PROTECTED]> wrote: > > My only other issue is that I need to write a plugin to "clean-up" my > > Tomcat META-INF/context.xml file to fix the DocBase to match the war > > file name, change debugging settings, etc. and have that run during > > the WAR process. > > Sounds like you need context.xml to be filtered - see MNG-791. This > will allow you to specify tokens in your context.xml and their values > in an associated filter.properties file. You can then supply > different filter.properties files depending on which profiles are > activated. > > Mark > -- Stephen Duncan Jr www.stephenduncanjr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
