On 27/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > On 27/09/2007, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > We should agree on strategy and the timing on executing it. I also agree > > that we need to involve everybody not just java folks. > > > > Actually, it is the Java that has these problems, because the other > languages are generally being worked on, on only one branch, or only by > one > group of people. It is the Java where the divergence between > groups/branches > is becoming a burden. Also, due to JMS, we can more easily write version > independent tests. Therefore, I think we can move Java tests without > consent > of non-java folks, so long as they are in general happy with the location > they are being moved to. >
OK - I'm really not sure what a /qpidtests buys us. I completely understand the idea of separating JUnit style unit tests from the tests which require a whole broker+client to be running. I completely agree with re-writing the tests which use InVM so that they can be run against a broker running outside the VM (e.g. the C++ broker). But why are we proposing moving tests out of /qpid and into /qpidtests. Sorry if I am being think... but what does this give us other than a more disjoint structure? And on Carl's excellent points, I would expand > 1.) to be able to run all the applicable tests from Java against both > brokers to be 1) To run *all* client tests (whatever language) against *any* broker (Java, C++, Rabbit, OpenAMQ or Other) There is nothing special about the Java client here... -- Rob
