Re: [Kissme-general] Re: Should I or not submit changes?

[Alex Lau <alex at dentonlive dot com>]

Stephen Crawley

> > I added your changes, but I can't figure out how to get the .in files to
> > be turned into .sh files.
> >    
> They would simply need to be added to the AC_CONFIG_FILES macro call in
> 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 couldn't find the mauve-kissme file ...
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 
those file.
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.
>  
Yup...

>  *  Someone has checked some files generated by autoconf, etcetera
>     (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.
who is the gate keeper for the cvs...this shouldn't be that diffcult to 
put in.

>  *  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
> libraries. ;)
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?


Alex