Yes, but we have decided that the new client for 0-10 will support the same JMS extensions are the old one for 0-8/M2 does. For non-JMS flags such as immediate and mandatory etc. So these tests are not actually JMS tests, but JMS+Qpid extension tests.
In order to run them accross any JMS implmentation, I propose to factor out the little bit of the framework that needs to be Qpid specific, and will only be used when the test is passed an option that requires it, into a separate class. If a test is running in pure JMS mode and is requested to run with a Qpid specific option, it can decline the invite. qpidtests/jmstests whatever, its just name... Rupert On 27/09/2007, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > On 27/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > Because, it makes absolutely certain that the version independent tests > we > > are running, are the same across all versionw, irrespective of branch. > > Arnaud has helpfully converted some of these tests on trunk to use JMS > > (perftests), but these changes have not made it onto the other branches. > > We > > have changed the tests on M2/2.1 to get them passing, but are having a > > hard > > time merging those valuable fixes down onto trunk. > > > > Hmmm - so we are proposing doing this because we are rubbish at source > control? :-) (pls note the smiley, I've been taken *too* seriously once > already today) > > So, the idea of these tests is that they are "independent of the version > of > Qpid". > > That must mean they depend on APIs which do not change with Qpid version. > Which (as far as I know) means they must be JMS tests? > > Is this correct so far? > > If they are jms tests then surely we should call them jmstests rather than > qpidtests? Any JMS provider will do? > > I'm not trying to be difficult... but I think that we need to be very > clear > about what we're doing here... and at the moment I'm really not in favour > of > moving things "out" of qpid. Moving them to a different directory under > qpid... fine... Maybe you can spin that out at a later date. > > Personally I'd much prefer to see this in qpid/jmstests > > I don't see the merging problems as being much worse than all the other > merging issues we have with multiple branches. > > -- Rob > > > > -- Rob >
