Bob, Thanks for digging into some of the controls test infrastructure!! I'm totally willing to help sort out any inconsistencies in the building of the tools and cleaning up of duplicate jars, etc.
Some thoughts on the test tools build. 1) Static jars of custom controls test tools Currently, we have checked in binary copies of most of the custom tools used by controls test with the thought that a) they don't change often and b) we'd like to shorten the build process so checking in binaries seemed a *relatively* safe bet. Of course, it is not ideal in some situations so I'm totally open to moving away from binary checkins and towards dynamic building. At a minimum a TCH deploy target should be added to controls/test/tools/build.xml. Also, Eddie and I had started a thread a while back about where test tools should go. Currently we deploy them into control/test/infra but there was some contention about whether or not that was the right place. Eddie's position was that artifacts of the build should be generated into a /build dir. I'm in full favor of this, especially if we move towards adding the test tools to the controls build process. 2) The TCH build I just went back to look at the TCH build process and it is pretty messed up! I'd love to see the work you've done to fix this up. If you need any help in this area I'm more than happy to help! TCH can be built if you have a unix style shell on your windows system (or are using a *nix system) and source 'setenv.sh' from controls/test/tools/tch) Work to be done there... 3) Multiple copies of jars Yes, there are some duplicates in the tree that should be cleaned up. If I remember correctly the reason for multiple copies of xbeans.jar was versioning. TCH uses version 1.0.2 but the copy that is in external is a stable snapshot from the xbeans HEAD and is version 2. There were some problems when we originally tried to build TCH with newer versions of xbeans. It would be worth looking at again to get TCH using the updated version (not to mention xbeans should be backwards compatible...) 4) Reorganizing tool projects (3rdparty -> lib, etc) I'm totally in favor of this. Almost all of the controls tools were developed in BEA over the years and were ripped apart and repackaged for Beehive but there are still some remnants of BEA days. Updating these projects to reflect Beehive project layout makes total sense. If you want to email me offline and let me know where you're at with these things and where you may want some help please feel free! #!/zach -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, October 31, 2004 9:30 AM To: [email protected] Subject: The build (controls/...) [[ Kyle, specific questions for you about 8 paragraphs down ]] Howdy guys-- So, I've spent the last few days realy digging into the build and the repository, starting with the controls/ subtree. As far as I could tell, controls/test/tools/ was not reproducible given the bits in the repo. Things like jakarta-regexp were missing, the build assumed some stubs/ directory for RMICing, and some native bits for javah'ing. There's several copies of xbeans.jar within that sub-tree, along with the one in external/ at the root. There seems to be two sets of TCH (controls/test/tools/.. and controls/test/infra/..). In cleaning that up, I've created a set of parallel build files (currently named 2build.xml so not to interfere with the existing build structure). I'll be preparing a tarball/zipfile for brave souls to grab and open on top of their repo for testing. With the talk of code-formatting clean-up for ApacheCon, I think we should also be looking at duplicate-removal for then. A nice side-effect my changes thus far has been the auto-setting of beehive.home without having to set BEEHIVE_HOME. And it even works from within deep in the tree. (Using <import> and ${ant.file.therootbuild} sort of magic). Also, now every sub-tree also checks for valid versions of ant/jdk. I have *not* made the ant-version-checking a priority in the sub-dirs, though, as we can assume if you're building lower in the tree, you know what you're doing. But at least we get friendly warnings for folks building from the root. Just checkout the repo, cd controls/test/tools/mantis/, type 'ant build' and it works nicely, including building tch when needed, etc. The last remaining task is getting the containers started/stopped during the test. Kyle, we'd spoken about abstracting the container stuff out so you can test on Tomcat, Geronimo, Jetty, etc, base upon a property setting, so I'd appreciate your concrete thoughts on that matter now. Once I get the build cleaned up across the entire repo, then I think we need to take some time to rmdir the duplicate bits of code, remove/readjust the location of extra jars (xbeans.jar is my archnemesis these days), and then finally adjust the layout to match other projects (lib/ instead of external/ or 3rdparty/, etc). -bob
