Attached is an HTML document with a little more description of my proposed changes to the way that Tests and Samples are handled in AXIS. Please note, most of this is what I have already done, and functioning with no regressions to function.
Please give me any feedback you feel appropriate, especially telling me where I need more detail / more description. I will try to get a "sample implementation" document together over the next few days so that you can better visualize the process flow.
(See attached file: AxisTestRedesign.html)
Matt Seibert [EMAIL PROTECTED]
IBM External: (512) 838-3656 Internal: 678-3656 Title: AXIS Test Rearchitecture
AXIS Test Rearchitecture
Common Design PrinciplesSamples Changes
Test Changes
Common Design Principles
There were 6 design goals that were laid out for me before undertaking this project:
- Determine the needs and dependancies of each test and sample
- Reduce the complexity of the xml that compiles, deploys, execs, and undeploys samples and tests
- Enable a new test or sample to be "plugged in" to the suites, without disturbing currently working things
- Enable the ability to instantiate any single sample or any single test
- Identify tests and samples that need "network" or "internet" resources
- Enable the ability to group tests and samples together in "bundles"
To this end, the general theory was applied to everything:
- Remove the neccessary steps that are in build.xml into build < thing >.xml (where < thing > is either "Samples" or "Test")
- Create a buildComponent.xml file in each samples/** and test/** directory
- Stub each buildComponent.xml with the following:
<?xml version="1.0" ?> <!-- =========================================================================================== --> <!-- Every project should begin with this next block --> <!-- =========================================================================================== --> < project name="< your_component_name_here >" default="compile"> < property file="build.properties"/> < property file="${user.home}/build.properties"/> < property file="test.properties"/> < property file="${user.home}/test.properties"/> < path id="classpath"> < pathelement location="${xerces.jar}"/> < pathelement location="${regexp.jar}"/> < pathelement location="${junit.jar}"/> < pathelement location="${excalibur.jar}"/> < pathelement location="${java.home}/../lib/tools.jar"/> < fileset dir="lib"> < include name="*.jar"/> </fileset> < pathelement location="${build.dest}"/> < pathelement path="${java.class.path}"/> </path> <!-- =========================================================================================== --> You now have read in the default build.properties file, and the default test.properties file If the user has an override for either of these in their home directory, these have been processed Then, we construct a classpath that includes, hopefully, all of the things that we would need. <!-- =========================================================================================== --> <!-- =========================================================================================== --> <!-- This target should remove anything created by this component --> <!-- =========================================================================================== --> < target name="clean"/> <!-- =========================================================================================== --> <!-- This target should copy in anything that this component needs, or copy out to staging --> <!-- This target should also do any neccessary "setup" tasks (manage pre-reqs, etc) --> <!-- =========================================================================================== --> < target name="copy"/> <!-- =========================================================================================== --> <!-- This target actually "makes" things --> <!-- =========================================================================================== --> < target name="compile"/> <!-- =========================================================================================== --> <!-- This target "deploys" this component if neccessary --> <!-- =========================================================================================== --> < target name="deploy"/> <!-- =========================================================================================== --> <!-- This target "runs" things in/for this component, if neccessary --> <!-- =========================================================================================== --> < target name="run"/> <!-- =========================================================================================== --> <!-- This target "undeploys" this component if neccessary --> <!-- =========================================================================================== --> < target name="undeploy"/> </project>
- If you want to instantiate this component directly, then add the following type stub into buildSamples.xml or buildTest.xml as appropriate:
< target name="echo"> < ant inheritAll="true" antfile="samples/echo/buildComponent.xml"/> </target>
This should be done if this sample/test is to be a dependancy of another sample or test. - If you don't want to instantiate it directly, the "compile" target looping in the buildSamples.xml or buildTest.xml file will pick up any buildComponent.xml files in the appropriate path.
- In order to reference a dependancy in a buildComponent.xml file, do the following (taken from test/soap/buildComponent.xml):
< target name="copy"> < ant inheritAll="true" antfile="buildTest.xml" target="utils"/> < ant inheritAll="true" antfile="buildTest.xml" target="RFCDispatch"/> </target>
Samples
The old $(TOP)/build.xml had a target called "samples" which did a very simple full-compile on everything referenced by samples/**/*.java. Although this was very simple, it was not very "strong" in that everything in the samples tree needed to be able to be compiled by this rule. Whenever anything needed to be altered in the samples, this main file needed to be modified. It was very possible for someone to add a sample that needed a change, and by changing the master file, could break a large number of things.
In order to alleviate this risk, and to better define the actual samples compilation and use, the samples building has been moved to a new xml file buildSamples.xml but the original target is still stubbed into build.xml for backwards compatibility and use does not change.
Then, I extracted the actual compilation logic for each sample, and componentized it into a buildComponent.xml file, located in the actual sample sub-directory. For example, for the echo sample is now run by the file samples/echo/buildComponent.xml. It can be singularly instantiated by invoking:
ant -buildfile buildSamples.xml echo
ant samples
Tests
The old $(TOP)/build.xml had a target called "buildTest" which did a very simple full-compile on every thing referenced by test/**/*.java. Although this was very simple, it was not very "strong" in that everything in the test tree needed to be able to be compiled by this rule. Whenever anything needed to be altered in the test, this main file needed to be modified. It was very possible for someone to add a test that needed a change, and by changing the master file, could break a large number of things.
In order to alleviate this risk, and to better define the actual test compilation and use, the test building has been moved to a new xml file buildTest.xml but the original target is still stubbed into build.xml for backwards compatibility and use does not change.
Then, I extracted the actual compilation logic for each test, and componentized it into a buildComponent.xml file, located in the actual test sub-directory. For example, for the session test is now compiled by the file test/session/buildComponent.xml. It can be singularly instantiated by invoking:
ant -buildfile buildTest.xml session
ant functional-tests