This is the mail archive of the mauve-discuss@sourceware.cygnus.com mailing list for the Mauve project. See the Mauve home page for more information.
Anthony Green wrote: > > Artur wrote: > > 1) I cannot check out latest mauve (cannot connect to cvs server) > > Can you give me details? (is it a cvs issue, or networking issue?) I > think if might be a good idea to make nightly tar-balls. Does anybody > think this is a bad idea? I think that it is problem with network. We still have quite bad inet here in Poland, so I would blame it, but I was able to checkout japhar, egcs or classpath changes at same time. Mauve and kaffe server were not answering - cvs was just doing nothing around for many minutes. I wasn't able to update kaffe sources also, so maybe it is fault at my side of network. > > 2) I'll convert it when it will be ready and working - until then it > > is easier to debug it in this form > > Ideally the simple framework supplied with the Mauve testsuite is > suitable for both (a) developing new test cases and (b) running the > entire suite. Do you have any suggestions for making (a) any easier? > It is, perhaps, a little tedious having to give the testlet names as > standard-in. Maybe we could support both standard-in _and_ command > line args? Why not in mauve framework ? 1) I use jbuilder for this particular class (because of very fast compile/error/correct/run turnabout). Mauve depends on magic shell scripts. I prefer to run in windows because I have 4 JDK versions here, with only one at linux (other thing is that linux has also kaffe and japhar, but they are not stable enought for me to build test on them) 2) I prefer fully verbose error messages. Of course I could add checkPassed() and checkFailed(message) methods to TestHarness, but this would give only "test 123456 of 12376317327 failed" in addition to my messages, which would just garble output 3) It is easier to manipulate file in top level package. People can run this test anywhere without setting it up inside mauve Of course, when it will be working, I plan to change it to mauve framework. I suppose that it will require changing all System.out.println to string operation with call to checkFailed(message) and adding else { harness.checkPassed(); } after each if (test) {...fail...} BTW do you want to build something on top of TestHarness in future ? I mean if it is important that every atomic test have its number. If not, then it will be easier, as each test could just call one pass/fail method at end (in addition to possible checkpoints for unxpected exceptions). I'm not sure for what such number could be used, but maybe some bug database ? In that case it would have to stay the same between mauve releases.... Artur