This is the mail archive of the
mailing list for the Mauve project.
Re: [Kissme-general] Re: Should I or not submit changes?
- From: Alex Lau <alex at dentonlive dot com>
- To: Stephen Crawley <crawley at dstc dot edu dot au>
- Cc: John Leuner <jewel at pixie dot co dot za>, kissme-general at lists dot sourceforge dot net, mauve-discuss at sources dot redhat dot com, Dalibor Topic <robilad at yahoo dot com>
- Date: Wed, 17 Jul 2002 10:23:39 -0500
- Subject: Re: [Kissme-general] Re: Should I or not submit changes?
- References: <200207170047.g6H0l3R11371@piglet.dstc.edu.au>
I couldn't find the mauve-kissme file ...
I added your changes, but I can't figure out how to get the .in files to
They would simply need to be added to the AC_CONFIG_FILES macro call in
be turned into .sh files.
Kissme's configure.ac file.
However ... I've looked at Alex's scripts, and concluded that it would be
better to use the 'mauve-kissme' key file that Mark Wielaard emailed last
week, especially if we can put that file into CVS.
I don't know how that key file look like, but I still have a hard time
using a key file to run that against Mauve... that's why I try to upload
Yes I know it is not an officeal way to run their test.... but it at
least able to
generate report for anything sub directory on any java and javax classes.
The problem is that if you run Mauve tests the way that the Mauve README
file says you should, the key file has to live in the Mauve directory.
This is real nuisance. [I can arrange that the Kissme make rules for
running the Mauve tests copy the key file to the place where Mauve
expects it to be ... but that's a HACK.]
That's a question I like to know. If Mauve mean to be a testing tool...
should the script for specific VM or Classpath located at Mauve CVS
or the other way?
If you look at the buildtest.sh script it, it basically just look through
the directory and find all the tests then build some classes files for it.
I just through that will be easier for everyone to test a subset of the
classpath rather then all classes or one class.
Here are some other beefs that I have with Mauve:
* Mauve's "make clean" doesn't delete the .class files.
* Someone has checked some files generated by autoconf, etceterawho is the gate keeper for the cvs...this shouldn't be that diffcult to
(configure and Makefile IIRC). These contain dependencies on
the version of autoconf, etcetera used on said person's machine
and break on my machine. These generated files need to be
removed from CVS.
* Mauve needs a global cvsignore file to ignore *.class files and
a .cvsignore file on the top directory to ignore the files created
by autoconf and configure.
* The Mauve configure.ac metascript should have a --with option for
specifying a directory or search path for finding key files.
The key option always confused me....
* The Mauve makefile should notice when I have edited the current
key file, and rebuild the class list file.
At the moment, I think that the class list only gets rebuilt
if you change the value of the KEYS environment variable.
is that right? no wonder I couldn't do anything to the class list.....
The keything is not very "user friendly" .... once again that is why I
try to put in those script to help me generate keys... I really would
like to start writing test cases... but before that I think we need a
more complete mauve to do that. The whole system need
someone to upkeep and make it work the way it should be...
( as a matter of fact for more then a month I still not sure how
should it really work .... )
Dalibor Topic wrote:
Porting tests over to Junit might not be too exciting,
though. I believe that (if the mauve hackers decide to
allow junit tests) it would be a better option to have
both frameworks in parallel for a while. As junit
relies on reflection, it wouldn't make much sense to
run it on an implementation with broken reflection
That's the trick I guess... if reflection is working :)
The question I always get is how much should the testing
tool depend on the VM and the Classpath?