The CargoTestSetup class that you added to the test framework (was this Wendy's first commit of Java code? :-) nicely leverages the fact that Cargo will figure out which container to use based on system properties (specifically "cargo.container.id"). However, the way that this class is being used in Tomcat5xWelcomeTestCase in the shale-blank application is definitely not container-agnostic, because it presumes to use Tomcat 5.x. I'd like to write our tests so that they dynamically adapt to whatever Cargo Container the user has selected in their ~/.m2/settings.xml file.
So, the question is, does the following strategy make sense? * Set up default cargo properties in the POM for a particular application (defauting to "tomcat5x" makes sense). * Allow the user to override these by setting up their favorite container in ~/.m2/settings.xml (presumes that user settings override POM settings) * Change the shale-blank tests to not bother trying to pass through any Tomcat specific properties -- instead, they should assume that all the required "cargo.*" propertes have been set up by the surrounding environment already. If this works out, it will make sense to replicate this model in the other apps that have integration tests, as well as into the archetype(s) for new applications. Craig
