This page gives a simple example of the kinds of thing we wanna do.
Assuming that all the test code is within a single Maven POM for now (e.g. activemq-integration-test version 4.0) which will deal with all the classpath issues.
We'll try describe the different ways this could work and give each implementation style a name so we can start revving different ways to solve this...
In this version there is no 'controller'; each build is considered to be a totally separate build.
Each build knows what to do; each test case generates an XML file which becomes a named deployment artifact.
e.g. imagine the following builds (which are really just running Java executables within a POM for classpath)
In the above example - each build has to kinda wait for other things to start up to some time period. e.g. the producer and consumer wanna keep around for say 5 minutes trying to connect to the broker as they can be started in any order.
Ideally we might wanna run this as 3 maven commands as follows...
The idea with the controller version is one of the tests (which is spun off first to try help) tries to coordinate among the test nodes.
e.g. we could spin the controller first...
Then the test case fires off these processes while communicating with them...
Fairly soon we're gonna have tons of builds firing off. We may want a single project to build with a raft of different test suites. Each single distributed integration/system/performance test might have many sub-builds (processes) to run.
So we might want to run a single JUnit test case which fires off different remote builds/processes.
So these 2 test cases in JUnit in the controller build will each start 3 separate remote builds on the queue and wait for them to complete - or terminate them