It took me a whole day but I did it. I wanted to integration MaxQ testing within a CruiseControl automatic build process.
Step 1 – Integrate application deployment in the build process
First of all, I had to deploy automatically the web application on Tomcat. Based on the work of Matt Raible (thanks Matt), I first defined a tomcatTask.properties
file defined as follow:
deploy=org.apache.catalina.ant.DeployTask install=org.apache.catalina.ant.InstallTask list=org.apache.catalina.ant.ListTask reload=org.apache.catalina.ant.ReloadTask remove=org.apache.catalina.ant.RemoveTask resources=org.apache.catalina.ant.ResourcesTask roles=org.apache.catalina.ant.RolesTask start=org.apache.catalina.ant.StartTask stop=org.apache.catalina.ant.StopTask undeploy=org.apache.catalina.ant.UndeployTask
Then I defined the task in the build.xml
file:
<taskdef file="tomcatTasks.properties"> <classpath> <pathelement path="${tomcat.home}/server/lib/catalina-ant.jar"/> </classpath> </taskdef>
Deploying a war is done using:
<target name="deploy-war" description="Deploy the war file on tomcat server"> <echo>+---------------------------------------------------+</echo> <echo>| |</echo> <echo>| DEPLOYING APPLICATION |</echo> <echo>| |</echo> <echo>+---------------------------------------------------+</echo> <deploy url="${tomcat.manager.url}" username="${tomcat.username}" password="${tomcat.password}" path="/${webapp.name}" war="file:${build.dir}/war/bomdb.war"/> <sleep minutes="1" /> </target>
The sleep of 1 minute is there only to be sure to start the tests after the application is fully initialized. It may be not necessary but on my build machine (quite old) it was.
Undeploying the war is done through:
<target name="undeploy-war" description="Undeploy the war file"> <echo>+---------------------------------------------------+</echo> <echo>| |</echo> <echo>| UNDEPLOY INTEGRATION TESTS |</echo> <echo>| |</echo> <echo>+---------------------------------------------------+</echo> <undeploy url="${tomcat.manager.url}" username="${tomcat.username}" password="${tomcat.password}" path="/${webapp.name}"/> </target>
Step 2 – integrating MaxQ and Ant
Looking at the MaxQ API, I found a ant task and try to implement it. I created a jar and defined a task in the build.xml
by defining a new task:
<taskdef name="maxq" classname="com.dfs.ant.taskdefs.optional.maxq.MaxqTask"> <classpath id="maxq.classpath"> <pathelement location="${lib.build.dir}/maxq.jar" /> <pathelement location="${lib.build.dir}/maxq-ant.jar" /> <pathelement location="${lib.build.dir}/junit-3.8.1.jar" /> <pathelement location="${ant.home}/lib/ant-junit.jar" /> <fileset dir="${maxq.dir}/lib"> <include name="*.jar"/> </fileset> <pathelement location="${lib.build.dir}/jython.jar" /> <pathelement location="${lib.dir}/commons-logging.jar" /> </classpath> </taskdef>
the ${maxq.dir}
defines the directory where maxq was installed.
It took me a while before being able to run the test scripts properly. With the ant task as it is in the CVS, I had some trouble with the script file name and the fact that I was not starting the tests from the root directory of the test scripts. So, I made some updates to the classes.
To launch the tests, I just add the following to the build file:
<delete dir="${inttest.xml.dir}"/> <mkdir dir="${inttest.xml.dir}"/> <maxq errorProperty="inttest.failed" failureProperty="inttest.failed" maxDir="${maxq.dir}" fork="no" > <classpath> <pathelement path="${inttest.xml.dir}" /> </classpath> <formatter classname="com.dfs.ant.taskdefs.optional.maxq.SummaryMaxqResultFormatter" usefile="false" /> <formatter type="xml" /> <batchtest todir="${inttest.xml.dir}" pythonPath="${jython.lib}"> <fileset dir="${maxq.test.src.dir}"> <include name="**/*.py" /> </fileset> </batchtest> </maxq>
The <formatter>
tags are just there because this part was integrated in a CruiseControl process.
So this is it!!
The only problem that left is the fact that making regular deploy/undeploy on the build machine seems to be highly memory consuming or that there is a memory leak somewhere. Whatever, it seems that I have to restart the tomcat server regulary.
Any idea to avoid that?