You can try using XDoclet. Using merge files you can do the following:
<XDtConfig:ifConfigParamEquals paramName="enable.cactus"
value="true">
<servlet-mapping>
<servlet-name>
ServletRedirector
</servlet-name>
<url-pattern>
/ServletRedirector
</url-pattern>
</servlet-mapping>
</XDtConfig:ifConfigParamEquals>
If you set enable.cactus =true in your ant build file, the servlet mappings will be
included in the web.xml file. Otherwise, they'll be excluded. You also need to set
conditions in your build file to include/exclude the necessary libraries during your
tests.
When you need production ear files, you just set enable.cactus(or whatever you name
the property) to false. None of the cactus files, libraries, or deployment entries
will be included in the build.
You can also use ant to dynamically set your cactus.properties file for different
deployment options.
Joe Milora
----- Original Message -----
From: "Andrew van der Voort" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 19, 2003 7:30 PM
Subject: Separating Cactus tests from the application
Hi. I have integrated the first of hopefully many tests into out
environment. Since I am testing struts actions, I should also say that I
have strutstestcase on the front of this, but I don't think it changes the
problem I am having.
My working environment is to have my application .war file built as normal.
Since I am using Cactus, I have added to the .war the following:
- Updated web.xml that specifies the ServletRedirector servlet mapping
- Required cactus and strutstestcase jars in WEB-INF/lib
- Test Cases built into a separate package structure
Naturally this .war is packaged up into a .ear for deployment on JBoss.
Everything works fine. However the problem with this approach is that the
.war file is not suitable for distribution to clients. It contains cactus
jars and classes that are not necessary.
What we want to do is prepare the application .ear without anything related
to unit testing in it, and package a separate .war or .ear with all the
testing classes and jars in it. This is so that once the testing is
complete, we can be confident that the .ear we have is good, and can be
distributed as-is.
Otherwise the only alternative is to package the .ear for testing, test,
and then repackage the .ear for distribution.
Can this be done?
Thanks, Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
