On Thu, 2007-09-27 at 11:29 +0100, Rupert Smith wrote: > Yes, stuff might be more correctly moved around. > > However, I would hold off moving anything at the moment. Reason is, > that it will complicate merging. Unless you are prepared to merge > everything down from M2/2.1 -> trunk first. There are a lot of test > fixes going on on M2.1 at the moment, so if you were to rearrange > trunk for example... it will become even more impossible than it > already is.
This is why I was suggesting to only add new tests to the client module for now and to do the move later. > One question, if you make tests in client start/stop a broker, will > that introduce a dependency from client -> broker? There already is > one, but it is a test dependency only. It should stay that way, or > else the client distro will pull in the broker too. For starting the broker you only assume that it is deployed somewhere. So, it can be the one that has been built just before the client module (a java broker indeed) or another one sitting on a dedicated server. I was thinking of three parameters that are: the launcher, the broker command and some additional parameters. For example, the parameters to run the tests against a c++ broker deployed on the same host would be: launcher=bash -c; broker=/usr/bin/qpid/src/qpidd; parameters=-d -p 0. If the tests are using an external broker I then spawn a process and destroy it when the test is completed. I am not sure that it would work well for remote brokers (running on a different machine) though. What we can do however is to use a Servlet or even a dedicated broker.
