This is the mail archive of the mailing list for the Mauve project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 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 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, 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 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]