Hi Erik! I wish I could offer more help but we've been struggling with basic Ant issues. Offhand I'd say use the filter-copy to modify the web.xml as you suggest. Maybe a token value like:
@redirector.mapping@ test.properties would contain: redirector.mapping=<...full mapping here...> prodcution.properties could contain: redirector.mapping=<!----> As to excluding the test classes, I think we keep them in a separate directory an explicitly include or exclude that directory from compilation. Cheers, Nick -----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] Sent: Friday, November 02, 2001 8:01 AM To: Cactus Users List Subject: Re: conditional building of Cactus deployments ----- Original Message ----- From: "Jim Cheesman" <[EMAIL PROTECTED]> > >* Some tests are non-Cactus JUnit tests. Some are Cactus. I'm separating > >them by directory structure. There needs to be a distinction in the Ant > >targets on which tests get run and such. > > > How/why do you want to distinguish between them? Because regular JUnit tests don't require an app. server installed. I want the flexibility to build and run just the plain ol' JUnit tests or step up to the Cactus ones separately. This piece is no big deal Ant-wise. > >* web.xml allow conditional inclusion of the redirector configuration > > Think about setting up (i.e. building then copying a war) a test > application. Then delete it. I don't quite understand what you mean. I want a production-quality web.xml that does not have the Cactus redirectors in there, and the capability to turn them on when building the test deployment. I'll figure out a way to handle this also either using filtered copy in Ant or some other way - I was just wondering what others were doing in this regard. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
