Mauve patches.

Mauve patches.

[Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've submitted several patches to both list and hear nothing; is there anyone 
who can comment/commit on these?

Please!
- -- 
Regards
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAcmKdCojCW6H2z/QRAvZpAKDd5gaoHFbHLIMM/RsAMWA5VSj2HgCgi4na
KTB8qTvzHh02ysf+loktnGI=
=OWa0
-----END PGP SIGNATURE-----

Re: Mauve patches.

[Michael Koch]

Am Dienstag, 6. April 2004 09:56 schrieb Thomas:
> I've submitted several patches to both list and hear nothing; is
> there anyone who can comment/commit on these?

We are all doing this in our freetime so we need some time nee out 
backlogs sometimes.

Personally I have Mauve CVS access but I'm using not using ant so I cant 
really vote on your patch. I think Tom Tromey or Mark Wielaard will 
look into this in some days. If not please ping me and I will do it.


Michael

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd really like to see my stuff committed, or commented on if just 
committing is unacceptable.

Are there any people actually maintaining mauve?  Nobody commented on the 
fixed needed for the website either.
In short who is the core maintainer for mauve?

On Tuesday 06 April 2004 10:46, Michael Koch wrote:
> Am Dienstag, 6. April 2004 09:56 schrieb Thomas:
> > I've submitted several patches to both list and hear nothing; is
> > there anyone who can comment/commit on these?
>
> We are all doing this in our freetime so we need some time nee out
> backlogs sometimes.
>
> Personally I have Mauve CVS access but I'm using not using ant so I cant
> really vote on your patch. I think Tom Tromey or Mark Wielaard will
> look into this in some days. If not please ping me and I will do it.
>
>
> Michael

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAdakLCojCW6H2z/QRAvPAAJ9VIVsdIvvJo9XvNIKvkKtho1FqgQCglYT1
004SB9mIxk/3Z8FF04TrxHE=
=dK+F
-----END PGP SIGNATURE-----

Re: Mauve patches.

[Michael Koch]

Am Donnerstag, 8. April 2004 21:33 schrieb Thomas Zander:
> I'd really like to see my stuff committed, or commented on if just
> committing is unacceptable.
>
> Are there any people actually maintaining mauve?  Nobody commented on
> the fixed needed for the website either.
> In short who is the core maintainer for mauve?

Mauve has no real maintainer. There are just some people that commit 
stuff in a chaotic way.

Michael

> On Tuesday 06 April 2004 10:46, Michael Koch wrote:
> > Am Dienstag, 6. April 2004 09:56 schrieb Thomas:
> > > I've submitted several patches to both list and hear nothing; is
> > > there anyone who can comment/commit on these?
> >
> > We are all doing this in our freetime so we need some time nee out
> > backlogs sometimes.
> >
> > Personally I have Mauve CVS access but I'm using not using ant so I
> > cant really vote on your patch. I think Tom Tromey or Mark Wielaard
> > will look into this in some days. If not please ping me and I will
> > do it.
> >
> >
> > Michael

Re: Mauve patches.

[Andrew Haley]

Michael Koch writes:
 > Am Donnerstag, 8. April 2004 21:33 schrieb Thomas Zander:
 > > I'd really like to see my stuff committed, or commented on if just
 > > committing is unacceptable.
 > >
 > > Are there any people actually maintaining mauve?  Nobody commented on
 > > the fixed needed for the website either.
 > > In short who is the core maintainer for mauve?
 > 
 > Mauve has no real maintainer. There are just some people that commit 
 > stuff in a chaotic way.

I have some patches for Mauve.  Thomas Zander's patch is one of them,
but it needs a little change to the ChangeLog entry to make it
standard.

I was intending to do it at the start of this week, sorry.

Andrew.

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 08 April 2004 21:56, Andrew Haley wrote:
>  > > I'd really like to see my stuff committed, or commented on if just
>  > > committing is unacceptable.
...
> I was intending to do it at the start of this week, sorry.

Its next week now; so your schedule was probably too full. (No offence!)

I hope you'll agree that its more important to have people creating patches 
and moving the project forward then to always have a 100% correct CVS. 
(problems can be fixed post-commit)
In that case; what about providing me with a writable CVS account so I 
won't have to bother you anymore.

Oh; and a explanation of the correct changelog format; or a link to that 
since you said there was something wrong with it; but I don't know what.

Hope to hear from you; Mauve is growing way too slow for my taste this way.

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAeOolCojCW6H2z/QRAtQNAKCeeKJpauJkytXf1iYfV8QDxv4H+gCfbYRw
6fhgQWbMbRMOwFI71OahauA=
=EvsI
-----END PGP SIGNATURE-----

Re: Mauve patches.

[David Lichteblau]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

Quoting Thomas Zander (zander@javalobby.org):
> I hope you'll agree that its more important to have people creating patches 
> and moving the project forward then to always have a 100% correct CVS. 
> (problems can be fixed post-commit)

No!


David
-- 
Common Lisp is the Borg of programming languages
	-- Bill Clementson

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mauve patches.

[Archie Cobbs]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UNKNOWN-8BIT, Size: 814 bytes --]

Thomas Zander wrote:
> On Thursday 08 April 2004 21:56, Andrew Haley wrote:
> >  > > I'd really like to see my stuff committed, or commented on if just
> >  > > committing is unacceptable.
> ...
> > I was intending to do it at the start of this week, sorry.
> 
> Its next week now; so your schedule was probably too full. (No offence!)
> 
> I hope you'll agree that its more important to have people creating patches 
> and moving the project forward then to always have a 100% correct CVS. 
> (problems can be fixed post-commit)
> In that case; what about providing me with a writable CVS account so I 
> won't have to bother you anymore.

Me too :-)

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 11 April 2004 14:22, David Lichteblau wrote:
> Quoting Thomas Zander (zander@javalobby.org):
> > I hope you'll agree that its more important to have people creating
> > patches and moving the project forward then to always have a 100%
> > correct CVS. (problems can be fixed post-commit)
>
> No!

David; I have not seen you before; an introduction might be in place.
After we found out what your part in Mauve is; would you care to elaborate 
on your position?
I'm assuming we all want the best java test suite there is; and in my 
experience the project is moving forward too slow to get that to happen. 
Instead of just shouting 'no!' an alternative solution is always welcome.

Thanx.

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAeX4ZCojCW6H2z/QRAtPDAJ9UsFw4/Rt4SKHlAbLVOMOnAGyE8QCgjLMP
S6M2ClKX4exsFt8aTu6HfG8=
=Ol2e
-----END PGP SIGNATURE-----

Re: Mauve patches.

[David Lichteblau]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]

Hi Thomas,

Quoting Thomas Zander (zander@javalobby.org):
> On Sunday 11 April 2004 14:22, David Lichteblau wrote:
> > Quoting Thomas Zander (zander@javalobby.org):
> > > I hope you'll agree that its more important to have people creating
> > > patches and moving the project forward then to always have a 100%
> > > correct CVS. (problems can be fixed post-commit)
> > No!
> David; I have not seen you before; an introduction might be in place.
> After we found out what your part in Mauve is;

I'm just yet another Mauve user.

> would you care to elaborate on your position?

Sure: "Problems should be fixed pre-commit."


BTW, to ask a technical question, is the "tagging" of Mauve testcases
used in practice?  Much of the complexity of the existing build systems
stems from the fact that tests are selected by a non-trivial script.  If
not for the tags, something like "find . -name \*.java" would be enough
to select all files.

Mark Wielaard sent an analysis of test suite failures for current
Classpath, which I found very helpful (thanks!).  When I am interested
to see whether the current Classpath version "works", which tags should
be used?  All of them, right?  

Unless I misunderstood Thomas' question, he could not compile all of
Mauve because his script tried to compile _everything_, as opposed to
those files usually chosen by the standard build system.  I would find
it a little confusing if Mauve provided two build systems, one which
uses tags and one which does not.


Thanks,
David

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> Unless I misunderstood Thomas' question, he could not compile all of
> Mauve because his script tried to compile _everything_, as opposed to
> those files usually chosen by the standard build system.  I would find
> it a little confusing if Mauve provided two build systems, one which
> uses tags and one which does not.

You did misunderstand my question;
the question is that I created a build system that only tests the classes I 
select (based on ant) and I want it committed; but there seems to be no 
maintainer that can comment on, or commit the patch.

My question therefor (to be exact) was that if some more freedom for 
not-yet-initiated coders is allowed, I would like to have a writable 
cvs-account which means I can continue working without waiting for more 
then a week.

Hope that clears it up.
- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAeZ5TCojCW6H2z/QRAt1GAJ9BozGa9R0Li6JhJyIIDvj8+q+9hgCfaEPr
bOVQl0rJWCtvYzH0mB+r2Jc=
=C+YF
-----END PGP SIGNATURE-----

Re: Mauve patches.

[C. Brian Jones]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

On Sun, 2004-04-11 at 15:36, Thomas Zander wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Unless I misunderstood Thomas' question, he could not compile all of
> > Mauve because his script tried to compile _everything_, as opposed to
> > those files usually chosen by the standard build system.  I would find
> > it a little confusing if Mauve provided two build systems, one which
> > uses tags and one which does not.
> 
> You did misunderstand my question;
> the question is that I created a build system that only tests the classes I 
> select (based on ant) and I want it committed; but there seems to be no 
> maintainer that can comment on, or commit the patch.
> 
> My question therefor (to be exact) was that if some more freedom for 
> not-yet-initiated coders is allowed, I would like to have a writable 
> cvs-account which means I can continue working without waiting for more 
> then a week.

Started doing some work over the weekend to add some tests to Mauve
based on another software package I've made that has non-Mauve related
functionality.  Anyway it seems to be somewhat difficult to add
something like this to Mauve, that has extensive data sets, a small
library not in the gnu.* namespace, etc.  I've started by trying to
define the problem and generalize on potential solutions.

Problems
 
* Cannot be installed (packaged, used repeatedly for various cases from
same install)
* No integrated pass/fail/expected/unexpected summary
* Repeated executions require knowing inner workings of
various scripts
* Integration of additional libraries difficult at best
* Integration of VM specific tests also difficult
 
Solutions
         
* Change configure script to be installation oriented, similar for
Makefile.am (started this already)
* New script(s) for running mauve to compile, execute, report
results (consider using dejagnu)
	* Specify java compiler at runtime
        * Specify vm at runtime
        * Specify temporary directory at runtime
	* Specify additional libraries/resources at runtime
	* Specify additional tests at runtime

Basically all the cruft and gorp in configure.in, Makefile.am, choose,
etc. gets done over.  The TAGS system is broken, it doesn't allow one to
specify that a particular test is only valid for 1.1, 1.2, 1.3 and not
1.4+, essential to handle deprecated methods that eventually get
removed.  I have no problem doing this work, my problem is all the
people that depend on the current directory structure, build process,
etc. that will scream if something is changed.  Anyway I have started
the work, when I have a patch I'll let the list review.  Don't hold your
breath, I'm slow sometimes.  :)

Thanks,
Brian
-- 
Brian Jones <cbj@gnu.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mauve patches.

[Andrew Haley]

David Lichteblau writes:
 > 
 > BTW, to ask a technical question, is the "tagging" of Mauve testcases
 > used in practice?

Yes, it is.

 > Much of the complexity of the existing build systems stems from the
 > fact that tests are selected by a non-trivial script.  If not for
 > the tags, something like "find . -name \*.java" would be enough to
 > select all files.

Well, sooner or later we'll be working with 1.5 (Java++?  :-) and at that
point it'll be pretty useful.  So let's keep it, please.

 > Unless I misunderstood Thomas' question, he could not compile all
 > of Mauve because his script tried to compile _everything_, as
 > opposed to those files usually chosen by the standard build system.
 > I would find it a little confusing if Mauve provided two build
 > systems, one which uses tags and one which does not.

Yes.  I suppose Thomas' Ant script should do the right thing with
respect to the tags.

Andrew.

Re: Mauve patches.

[Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 13 April 2004 15:19, you wrote:
> David Lichteblau writes:
>  > Unless I misunderstood Thomas' question, he could not compile all
>  > of Mauve because his script tried to compile _everything_, as
>  > opposed to those files usually chosen by the standard build system.
>  > I would find it a little confusing if Mauve provided two build
>  > systems, one which uses tags and one which does not.
>
> Yes.  I suppose Thomas' Ant script should do the right thing with
> respect to the tags.

The selecting of files based on some 'tag in their content is quite easy in 
ant; its a standard target.
I could add an ant-build target that builds based on tags.

Sorry fly to David for not fully understanding the above paragraph the first 
time I replied to it! (And giving an answer that did not it justice).
- -- 
Regards
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAe/F8CojCW6H2z/QRAvTJAKDLBfvoky2GpU+G3rezejPRZ4sPzACg1K62
7qtMb1oEi3sOSShNuLHDSAs=
=+joY
-----END PGP SIGNATURE-----

Re: Mauve patches.

[Andrew Haley]

Thomas writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Tuesday 13 April 2004 15:19, you wrote:
 > > David Lichteblau writes:
 > >  > Unless I misunderstood Thomas' question, he could not compile all
 > >  > of Mauve because his script tried to compile _everything_, as
 > >  > opposed to those files usually chosen by the standard build system.
 > >  > I would find it a little confusing if Mauve provided two build
 > >  > systems, one which uses tags and one which does not.
 > >
 > > Yes.  I suppose Thomas' Ant script should do the right thing with
 > > respect to the tags.
 > 
 > The selecting of files based on some 'tag in their content is quite easy in 
 > ant; its a standard target.
 > I could add an ant-build target that builds based on tags.

Excellent.  Now I feel not so bad for being slow to commit...

Andrew.

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 13 April 2004 16:29, Andrew Haley wrote:
> Thomas writes:
>  > On Tuesday 13 April 2004 15:19, you wrote:
>  > > Yes.  I suppose Thomas' Ant script should do the right thing with
>  > > respect to the tags.
>  >
>  > The selecting of files based on some 'tag in their content is quite
>  > easy in ant; its a standard target.
>  > I could add an ant-build target that builds based on tags.
>
> Excellent.  Now I feel not so bad for being slow to commit...

Hmm; I kind of (really) like working in CVS, its like a net that catches 
you when you fail (and more).
What about you commit first; then I can safely start to work on adding 
extra features.
I mean; all the questions I posed have been quietly been ignored, I'm not 
really under the impression Mauve is getting the attention it deserves; I 
honestly begin starting to wonder if putting it in a CVS on sourceforge or 
whereever, and more freely giving out CVS accounts is such a bad idea.

Some rights to commit and/or to clean up the webpages is the only thing 
standing in my way to really help make Mauve move forward!
- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfB/LCojCW6H2z/QRAp7eAKDCzNrGAZhIg9c4mLaje2RmIY7/gACeIQ5k
wsvu26crbD4glB6ncSiqUlo=
=sJxK
-----END PGP SIGNATURE-----

Re: Mauve patches.

[Andrew Haley]

Thomas Zander writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Tuesday 13 April 2004 16:29, Andrew Haley wrote:
 > > Thomas writes:
 > >  > On Tuesday 13 April 2004 15:19, you wrote:
 > >  > > Yes.  I suppose Thomas' Ant script should do the right thing with
 > >  > > respect to the tags.
 > >  >
 > >  > The selecting of files based on some 'tag in their content is quite
 > >  > easy in ant; its a standard target.
 > >  > I could add an ant-build target that builds based on tags.
 > >
 > > Excellent.  Now I feel not so bad for being slow to commit...
 > 
 > Hmm; I kind of (really) like working in CVS, its like a net that catches 
 > you when you fail (and more).
 > What about you commit first; then I can safely start to work on adding 
 > extra features.

Alright.

 > I mean; all the questions I posed have been quietly been ignored, I'm not 
 > really under the impression Mauve is getting the attention it deserves; I 
 > honestly begin starting to wonder if putting it in a CVS on sourceforge or 
 > whereever, and more freely giving out CVS accounts is such a bad idea.

Actually, all the questions you posed have not quietly been ignored.
I have answered some of them.

 > Some rights to commit and/or to clean up the webpages is the only
 > thing standing in my way to really help make Mauve move forward!

That and the fact that as yet you have not managed correctly to submit
a patch.  I have attached a version here, FYI.

I don't think I've broken anything with the checkin, but please check.

Andrew.


2004-04-13  Thomas Zander <zander@kde.org>

        * build.xml: New file.
        * gnu/anttask/RunTests.java: New file.
        * gnu/testlet/SimpleTestHarness.java (getFailures): New method.

        * gnu/testlet/javax/swing/JLabel/Icon.java: New file.
        * gnu/testlet/javax/swing/JLabel/Mnemonic.java: New file.

        * gnu/testlet/java/text/SimpleDateFormat/attribute.java 
        (test_FieldPos): Locals no longer static.
 
Index: build.xml
===================================================================
RCS file: build.xml
diff -N build.xml
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- build.xml	13 Apr 2004 17:38:48 -0000
***************
*** 0 ****
--- 1,87 ----
+ <?xml version="1.0"?>
+ <!--Copyright (c) 2004 Thomas Zander <zander@kde.org>
+ 
+     This file is part of Mauve.
+ 
+     Mauve is free software; you can redistribute it and/or modify
+     it under the terms of the GNU General Public License as published by
+     the Free Software Foundation; either version 2, or (at your option)
+     any later version.
+ 
+     Mauve is distributed in the hope that it will be useful,
+     but WITHOUT ANY WARRANTY; without even the implied warranty of
+     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     GNU General Public License for more details.
+ 
+     You should have received a copy of the GNU General Public License
+     along with Mauve; see the file COPYING.  If not, write to
+     the Free Software Foundation, 59 Temple Place - Suite 330,
+     Boston, MA 02111-1307, USA. -->
+ 
+ <project name="mauve" default="test" basedir=".">
+ 
+     <!-- this loads the ant global properties -->
+     <property file="${user.home}/.ant-global.properties"/>
+ 
+     <property name="src" value="."/>
+     <property name="build" value="build"/>
+     <property name="docs" value="doc"/>
+ 
+     <!-- clean up .class and .jar files -->
+     <target name="clean" description="Clean out compiled files">
+         <!-- call clean from example-buildfile -->
+         <delete dir="${build}"/>
+         <delete dir="${docs}"/>
+     </target>
+ 
+     <!-- INIT creates the required directories and files -->
+     <target name="init">
+         <tstamp/>
+         <mkdir dir="${build}"/>
+         <mkdir dir="${docs}"/>
+         <!-- if ant runs; we can be pretty sure these are correct. -->
+         <filter token="SRCDIR" value="${user.dir}"/>
+         <filter token="TMPDIR" value="${java.io.tmpdir}" />
+         <filter token="CHECK_PATH_SEPARATOR" value="${path.separator}"/>
+         <filter token="CHECK_FILE_SEPARATOR" value="${file.separator}"/>
+         <copy file="${src}/gnu/testlet/config.java.in"
+                 tofile="${src}/gnu/testlet/config.java"
+                 verbose="true"
+                 filtering="true" />
+     </target>
+ 
+     <!-- CLASSPATH -->
+     <path id="myclass.path">
+         <pathelement location="${build}" />
+     </path>
+ 
+     <!-- compiles all the sources -->
+     <target name="compile" depends="init" description="Compile all files">
+         <javac srcdir="${src}" destdir="${build}"
+             includes="gnu/**/*.java"
+             exlucdes="gnu/testlet/BinaryCompatibility/**"
+             classpathref="myclass.path"
+             debug="on" />
+     </target>
+ 
+     <target name="doc" depends="init" description="Build javadoc">
+         <javadoc packagenames="gnu.testlet"
+             defaultexcludes="yes"
+             destdir="${docs}/"
+             classpathref="myclass.path"
+             windowtitle="Mauve test API" >
+             <doctitle><![CDATA[<h1>Mauve test API</h1>]]></doctitle>
+         </javadoc>
+     </target>
+ 
+     <target name="test" depends="init,compile" description="run the tests">
+         <taskdef name="mauve" classname="gnu.anttask.RunTests" classpath="build"/>
+         <mauve debug="false"
+             verbose="false"
+             haltonfailure="false"
+             failonerror="true">
+             <fileset dir="${build}" includes="gnu/testlet/java/**" />
+             <fileset dir="${build}" includes="gnu/testlet/javax/**" />
+         </mauve>
+     </target>
+ </project>
Index: gnu/anttask/RunTests.java
===================================================================
RCS file: gnu/anttask/RunTests.java
diff -N gnu/anttask/RunTests.java
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- gnu/anttask/RunTests.java	13 Apr 2004 17:38:48 -0000
***************
*** 0 ****
--- 1,101 ----
+ /*
+ Copyright (c) 2004 Thomas Zander <zander@kde.org>
+ 
+ This file is part of Mauve.
+ 
+ Mauve is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+ 
+ Mauve is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with Mauve; see the file COPYING.  If not, write to
+ the Free Software Foundation, 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA. */
+ 
+ package gnu.anttask;
+ 
+ import gnu.testlet.*;
+ import java.io.*;
+ import java.util.*;
+ 
+ import org.apache.tools.ant.*;
+ import org.apache.tools.ant.taskdefs.*;
+ import org.apache.tools.ant.types.*;
+ 
+ public class RunTests extends MatchingTask {
+     private boolean verbose=false, debug=false, haltOnFailure=false, failOnError=true;
+     private Path sourceDir=null;
+     private Vector filesets=new Vector();
+ 
+     public void execute() throws BuildException {
+         MyTestHarness harness = new MyTestHarness (verbose, debug, haltOnFailure);
+ 
+         Iterator iter = filesets.iterator();
+         while(iter.hasNext()) {
+             FileSet fs = (FileSet) iter.next();
+             try {
+                 DirectoryScanner ds = fs.getDirectoryScanner(getProject());
+                 Iterator classNames = Arrays.asList(ds.getIncludedFiles()).iterator();
+                 while(classNames.hasNext()) {
+                     String filename = (String) classNames.next();
+                     if(! filename.endsWith(".class"))
+                         continue; // only class files
+                     if(filename.lastIndexOf("$") > filename.lastIndexOf(File.separator))
+                         continue; // no inner classeS
+                     filename=filename.substring(0, filename.length()-6);
+                     filename=filename.replace(File.separatorChar, '.');
+ 
+                     harness.runTest(filename);
+                 }
+             } catch (BuildException be) {
+                 // directory doesn't exist or is not readable
+                 if (failOnError)
+                     throw be;
+                 else
+                     log(be.getMessage(),Project.MSG_WARN);
+             }
+         }
+     }
+ 
+     public void setVerbose(boolean verbose) {
+         this.verbose = verbose;
+     }
+ 
+     public void setDebug(boolean debug) {
+         this.debug = debug;
+     }
+ 
+     public void setHaltOnFailure(boolean on) {
+         haltOnFailure = on;
+     }
+ 
+     public void setFailOnError(boolean on) {
+         failOnError = on;
+     }
+ 
+     public void addFileset(FileSet set) {
+         filesets.add(set);
+     }
+ 
+ 
+     private static class MyTestHarness extends SimpleTestHarness {
+         private boolean haltOnFailure;
+         // extend it b/cause someone thought it should not have public constructors.
+         public MyTestHarness(boolean verbose, boolean debug, boolean haltOnFailure) {
+             super(verbose, debug, false);
+             this.haltOnFailure = haltOnFailure;
+         }
+ 
+         protected void runTest (String name) throws BuildException {
+             super.runtest(name);
+             if(haltOnFailure && getFailures() > 0)
+                 throw new BuildException("Failures");
+         }
+     }
+ }
Index: gnu/testlet/SimpleTestHarness.java
===================================================================
RCS file: /cvs/mauve/mauve/gnu/testlet/SimpleTestHarness.java,v
retrieving revision 1.38
diff -p -2 -c -r1.38 SimpleTestHarness.java
*** gnu/testlet/SimpleTestHarness.java	29 Aug 2003 14:52:21 -0000	1.38
--- gnu/testlet/SimpleTestHarness.java	13 Apr 2004 17:38:48 -0000
*************** public class SimpleTestHarness
*** 51,54 ****
--- 51,59 ----
    }
    
+ 
+   protected int getFailures() {
+     return failures;
+   }
+ 
    public void check (boolean result)
    {
Index: gnu/testlet/java/text/SimpleDateFormat/attribute.java
===================================================================
RCS file: /cvs/mauve/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java,v
retrieving revision 1.1
diff -p -2 -c -r1.1 attribute.java
*** gnu/testlet/java/text/SimpleDateFormat/attribute.java	24 Mar 2004 20:21:29 -0000	1.1
--- gnu/testlet/java/text/SimpleDateFormat/attribute.java	13 Apr 2004 17:38:48 -0000
*************** public class attribute implements Testle
*** 158,170 ****
  	SimpleDateFormat format = new SimpleDateFormat("yyyy.MM.dd hh:kk:mm:ss 'zone' zzzz");
  	Date date = new Date();
! 	static Format.Field[] fields = new Format.Field[] {
  	  DateFormat.Field.YEAR,  DateFormat.Field.MONTH, DateFormat.Field.DAY_OF_MONTH,
  	  DateFormat.Field.HOUR1, DateFormat.Field.HOUR_OF_DAY1, DateFormat.Field.MINUTE,
  	  DateFormat.Field.SECOND
  	};
! 	static int[] begin = new int[] {
  	  0, 5, 8, /***/  11, 14, 17, 20
  	};
! 	static int[] end = new int[] {
  	  4, 7, 10, /***/ 13, 16, 19, 22
  	};
--- 158,170 ----
  	SimpleDateFormat format = new SimpleDateFormat("yyyy.MM.dd hh:kk:mm:ss 'zone' zzzz");
  	Date date = new Date();
! 	Format.Field[] fields = new Format.Field[] {
  	  DateFormat.Field.YEAR,  DateFormat.Field.MONTH, DateFormat.Field.DAY_OF_MONTH,
  	  DateFormat.Field.HOUR1, DateFormat.Field.HOUR_OF_DAY1, DateFormat.Field.MINUTE,
  	  DateFormat.Field.SECOND
  	};
! 	int[] begin = new int[] {
  	  0, 5, 8, /***/  11, 14, 17, 20
  	};
! 	int[] end = new int[] {
  	  4, 7, 10, /***/ 13, 16, 19, 22
  	};
Index: gnu/testlet/javax/swing/JLabel/Icon.java
===================================================================
RCS file: gnu/testlet/javax/swing/JLabel/Icon.java
diff -N gnu/testlet/javax/swing/JLabel/Icon.java
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- gnu/testlet/javax/swing/JLabel/Icon.java	13 Apr 2004 17:38:48 -0000
***************
*** 0 ****
--- 1,75 ----
+ // Tags: JDK1.2
+ 
+ // Copyright (C) 2004 Thomas Zander <zander@kde.org>
+ 
+ // This file is part of Mauve.
+ 
+ // Mauve is free software; you can redistribute it and/or modify
+ // it under the terms of the GNU General Public License as published by
+ // the Free Software Foundation; either version 2, or (at your option)
+ // any later version.
+ 
+ // Mauve is distributed in the hope that it will be useful,
+ // but WITHOUT ANY WARRANTY; without even the implied warranty of
+ // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ // GNU General Public License for more details.
+ 
+ // You should have received a copy of the GNU General Public License
+ // along with Mauve; see the file COPYING.  If not, write to
+ // the Free Software Foundation, 59 Temple Place - Suite 330,
+ // Boston, MA 02111-1307, USA.
+ 
+ package gnu.testlet.javax.swing.JLabel;
+ 
+ import gnu.testlet.Testlet;
+ import gnu.testlet.TestHarness;
+ import java.util.EventListener;
+ import java.awt.*;
+ import javax.swing.*;
+ 
+ /**
+  * These tests pass with the Sun JDK 1.4.1_03 on GNU/Linux IA-32.
+  */
+ public class Icon implements Testlet {
+     public void test(TestHarness harness) {
+         MyIcon icon = new MyIcon();
+         JLabel l = new JLabel(icon);
+         harness.check(l.getIcon(), icon);
+         harness.check(l.getDisabledIcon(), null);
+         l.setIcon(icon);
+         harness.check(l.getIcon(), icon);
+         harness.check(l.getDisabledIcon(), null);
+ 
+         l = new JLabel();
+         Dimension base = l.getPreferredSize();
+         l.setIcon(icon);
+         Dimension one = l.getPreferredSize();
+         harness.check(one.width, base.width + icon.getIconWidth());
+ 
+         l = new JLabel("bla");
+         base = l.getPreferredSize();
+         l.setIcon(icon);
+         one = l.getPreferredSize();
+         harness.check(one.width, base.width + icon.getIconWidth() + l.getIconTextGap() );
+ 
+         l.setIconTextGap(100);
+         one = l.getPreferredSize();
+         harness.check(one.width, base.width + icon.getIconWidth() + 100 );
+     }
+ 
+     private static class MyIcon implements javax.swing.Icon {
+         private int painted = 0;
+         public int getIconHeight()  {
+             return 10;
+         }
+         public int getIconWidth()  {
+             return 20;
+         }
+         public void paintIcon(Component c, Graphics g, int x, int y)  {
+             painted++;
+         }
+         public int getPainted() {
+             return painted;
+         }
+     }
+ }
Index: gnu/testlet/javax/swing/JLabel/Mnemonic.java
===================================================================
RCS file: gnu/testlet/javax/swing/JLabel/Mnemonic.java
diff -N gnu/testlet/javax/swing/JLabel/Mnemonic.java
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- gnu/testlet/javax/swing/JLabel/Mnemonic.java	13 Apr 2004 17:38:48 -0000
***************
*** 0 ****
--- 1,61 ----
+ // Tags: JDK1.2
+ 
+ // Copyright (C) 2004 Thomas Zander <zander@kde.org>
+ 
+ // This file is part of Mauve.
+ 
+ // Mauve is free software; you can redistribute it and/or modify
+ // it under the terms of the GNU General Public License as published by
+ // the Free Software Foundation; either version 2, or (at your option)
+ // any later version.
+ 
+ // Mauve is distributed in the hope that it will be useful,
+ // but WITHOUT ANY WARRANTY; without even the implied warranty of
+ // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ // GNU General Public License for more details.
+ 
+ // You should have received a copy of the GNU General Public License
+ // along with Mauve; see the file COPYING.  If not, write to
+ // the Free Software Foundation, 59 Temple Place - Suite 330,
+ // Boston, MA 02111-1307, USA.
+ 
+ package gnu.testlet.javax.swing.JLabel;
+ 
+ import gnu.testlet.Testlet;
+ import gnu.testlet.TestHarness;
+ import java.util.EventListener;
+ import javax.swing.JLabel;
+ 
+ /**
+  * These tests pass with the Sun JDK 1.4.1_03 on GNU/Linux IA-32.
+  */
+ public class Mnemonic implements Testlet {
+     public void test(TestHarness harness) {
+         JLabel l = new JLabel("lskdjnvmdsklzedfsdmnWK");
+         harness.check(l.getDisplayedMnemonic(), 0);
+         harness.check(l.getDisplayedMnemonicIndex(), -1);
+ 
+         l.setDisplayedMnemonic(java.awt.event.KeyEvent.VK_K);
+         harness.check(l.getDisplayedMnemonic(), java.awt.event.KeyEvent.VK_K);
+         harness.check(l.getDisplayedMnemonicIndex(), 2);
+ 
+         l.setDisplayedMnemonic(java.awt.event.KeyEvent.VK_Q);
+         harness.check(l.getDisplayedMnemonicIndex(), -1);
+ 
+         l.setDisplayedMnemonic(java.awt.event.KeyEvent.VK_W);
+         harness.check(l.getDisplayedMnemonicIndex(), 20);
+ 
+         l.setText("new text");
+         harness.check(l.getDisplayedMnemonicIndex(), 2);
+ 
+         l.setDisplayedMnemonicIndex(5);
+         // the following test is really un-intuitive... Is this a bug in Suns JVM?
+         harness.check(l.getDisplayedMnemonic(), java.awt.event.KeyEvent.VK_W); // unchanged
+         harness.check(l.getDisplayedMnemonicIndex(), 5);
+ 
+         l = new JLabel("new text");
+         l.setDisplayedMnemonicIndex(5);
+         harness.check(l.getDisplayedMnemonic(), 0);
+         harness.check(l.getDisplayedMnemonicIndex(), 5);
+     }
+ }

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 13 April 2004 19:44, Andrew Haley wrote:
>  >
>  > Hmm; I kind of (really) like working in CVS, its like a net that
> catches > you when you fail (and more).
>  > What about you commit first; then I can safely start to work on
> adding > extra features.
>
> Alright.

Thank you.

>  > I mean; all the questions I posed have been quietly been ignored, I'm
> not > really under the impression Mauve is getting the attention it
> deserves; I > honestly begin starting to wonder if putting it in a CVS
> on sourceforge or > whereever, and more freely giving out CVS accounts
> is such a bad idea.
>
> Actually, all the questions you posed have not quietly been ignored.
> I have answered some of them.
Indeed, I stand corrected, you did answer some of them.

>  > Some rights to commit and/or to clean up the webpages is the only
>  > thing standing in my way to really help make Mauve move forward!
>
> That and the fact that as yet you have not managed correctly to submit
> a patch.  I have attached a version here, FYI.
>
> I don't think I've broken anything with the checkin, but please check.

Hmm; I'm wondering what was wrong with the last patch I sent; the only 
difference I see is that I failed to mention the new method in 
SimpleTestHarness, and the change in statics in 
SimpleDateFormat/attribute.java.
Was it a bad choice to sent it as a bzip2 compressed patch?

Anyway; you forgot this thingy:

diff -U3 -p -N -r mauve-orig/.cvsignore mauve-new/.cvsignore
- --- mauve-orig/.cvsignore	2004-04-03 17:59:23.000000000 +0200
+++ mauve-new/.cvsignore	2004-04-03 17:55:59.000000000 +0200
@@ -9,3 +9,5 @@ config.status
 dataoutput.out
 utf8test.out
 todos.txt
+build
+doc

Cheers!
- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfDhcCojCW6H2z/QRAr6bAKC4sunY3qwseVScgx6QpTaIFrQOHwCgn2tD
wI68OhAeY52gyBerWTLo7As=
=WGVb
-----END PGP SIGNATURE-----

Re: Mauve patches.

[Bill McFadden]

>Thomas wrote:
>> David Lichteblau writes:
>> Yes.  I suppose Thomas' Ant script should do the right thing with
>> respect to the tags.
>
>The selecting of files based on some 'tag in their content is quite easy in
>ant; its a standard target.  I could add an ant-build target that builds
>based on tags.

A build.xml that does the JDK1.1 tests would be terrific.  I was
unsuccessful building Mauve from the instructions in README, but Thomas's
Ant script worked.

--
Bill McFadden    billmc@agora.rdrop.com    http://www.rdrop.com/users/billmc
CAUTION: Don't look into laser beam with remaining eye.

Re: Mauve patches.

[Andrew Haley]

Thomas Zander writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Tuesday 13 April 2004 19:44, Andrew Haley wrote:
 > > I have attached a version here, FYI.
 > >
 > > I don't think I've broken anything with the checkin, but please check.
 > 
 > Hmm; I'm wondering what was wrong with the last patch I sent; the only 
 > difference I see is that I failed to mention the new method in 
 > SimpleTestHarness, and the change in statics in 
 > SimpleDateFormat/attribute.java.

This is what you sent:

diff -U3 -p -N -r mauve-orig/ChangeLog mauve/ChangeLog
--- mauve-orig/ChangeLog        2004-04-03 17:59:25.000000000 +0200
+++ mauve/ChangeLog     2004-04-03 17:54:08.000000000 +0200
@@ -1,4 +1,17 @@
+2004-04-03  Thomas Zander <zander@kde.org>
+
+       * new files
+       gnu/testlet/javax/swing/JLabel/Icon.java,
+       gnu/testlet/javax/swing/JLabel/Mnemonic.java
+
+2004-04-03  Thomas Zander <zander@kde.org>
+
+       * added an ant build option so the autotools are not needed if you use
+       a fully functional JVM (for example for writing tests).
+       build.xml:  ant build file
+       gnu/anttask/RunTests.java: ant task for calling SimpleTestHarness.java
+

This is what I did to make it right:

2004-04-13  Thomas Zander <zander@kde.org>

        * build.xml: New file.
        * gnu/anttask/RunTests.java: New file.
        * gnu/testlet/SimpleTestHarness.java (getFailures): New method.

        * gnu/testlet/javax/swing/JLabel/Icon.java: New file.
        * gnu/testlet/javax/swing/JLabel/Mnemonic.java: New file.

        * gnu/testlet/java/text/SimpleDateFormat/attribute.java 
        (test_FieldPos): Locals no longer static.

See http://www.gnu.org/prep/standards_42.html#SEC42. 

Note in particular that Change Logs document only what, not why.
Explanations should be comments in the program.

 > Was it a bad choice to sent it as a bzip2 compressed patch?

Not always, but it does mean that reviewers are less likely to look at
your patch straight away.

 > Anyway; you forgot this thingy:
 > 
 > diff -U3 -p -N -r mauve-orig/.cvsignore mauve-new/.cvsignore

Ah, yes.  Thanks.

Andrew.

Re: Mauve patches.

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

Hi Thomas,

On Sun, 2004-04-11 at 08:48, Thomas Zander wrote:
> Oh; and a explanation of the correct changelog format; or a link to that 
> since you said there was something wrong with it; but I don't know what.

Look at the new and improved GNU Classpath Hackers Guide:
(7.1 Documenting what changed when with ChangeLog entries)
http://www.gnu.org/software/classpath/docs/hacking.html#SEC9

> Hope to hear from you; Mauve is growing way too slow for my taste this way.

My apologies for not following up on this sooner.
I am happy that Andrew helped you out.

Your help is really appreciated. Especially since we are all short on
time. So, please don't see the slow reactions as rejections of your
work. I am really, really happy you want to pick this up and make it
easier for others. Mauve is very important but indeed far to difficult
to setup and hack on.

Thanks,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mauve patches.

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

Hi,

On Sun, 2004-04-11 at 20:57, David Lichteblau wrote:
> Quoting Thomas Zander (zander@javalobby.org):
> > On Sunday 11 April 2004 14:22, David Lichteblau wrote:
> > > Quoting Thomas Zander (zander@javalobby.org):
> > > > I hope you'll agree that its more important to have people creating
> > > > patches and moving the project forward then to always have a 100%
> > > > correct CVS. (problems can be fixed post-commit)
> > > No!
> >
> > would you care to elaborate on your position?
>
> Sure: "Problems should be fixed pre-commit."

I agree. Mauve is actually used daily by people (me). And some people
even use it in autobuilders/testers which are updated from CVS.

> BTW, to ask a technical question, is the "tagging" of Mauve testcases
> used in practice?  Much of the complexity of the existing build systems
> stems from the fact that tests are selected by a non-trivial script.  If
> not for the tags, something like "find . -name \*.java" would be enough
> to select all files.

There are Tags to select which test (sets) you want to run. But also
Uses which declare what a test depends on. That is needed to make sure
you compile all java source files needed and only those files.

> Mark Wielaard sent an analysis of test suite failures for current
> Classpath, which I found very helpful (thanks!).  When I am interested
> to see whether the current Classpath version "works", which tags should
> be used?  All of them, right?  

Yes. I am using:
KEYS="JDK1.0 JDK1.1 JDK1.2 JDK1.3 JDK1.4 JLS1.0 JLS1.2 JDBC1.0 JDBC2.0 JAVA2"
And I used to add !java.lang.Character.unicode since that was broken
till next week (thanks Stephan!).

> Unless I misunderstood Thomas' question, he could not compile all of
> Mauve because his script tried to compile _everything_, as opposed to
> those files usually chosen by the standard build system.  I would find
> it a little confusing if Mauve provided two build systems, one which
> uses tags and one which does not.

Actually Mauve already provides two mechanism. I secretly (well, there
is a changelog entry and some discussion on the mailinglist) added a
second method last year. The way the Makefile works does indeed try to
compile everything you tagged/choose at once and then run all those
tests in one go. I added a little batch_run and runner (bash shell)
script that actually uses the choose script to compile each test (and
dependent source file) separately and then run each test separately
(installing a timer to catch a hanging runtime). Unfortunately I never
documented that in the README. And it also doesn't work nicely with the
configure script. You actually have to edit the used compiler (COMPILER)
in batch_run and the used runtime (RUNTIME) in runner. But it is nice
for those times that a test doesn't compile or hangs/crashed the
runtime, then you just get one failure and the rest of the tests are
still run.

(There is actually even a third build system for mauve. It is embedded
in an expect script inside libgcj gcc/libjava/testsuite that does kind
of what the above shell script does, but then runs each test both with a
traditional byte code interpreter and compiled as native code.)

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mauve patches.

[Anthony Green]

On Sun, 2004-04-11 at 21:12, C. Brian Jones wrote:
> * Cannot be installed (packaged, used repeatedly for various cases from
> same install)

I'm not sure why you would want to "install" mauve.  I guess I'm too
used to how we use Mauve with libgcj.

> * No integrated pass/fail/expected/unexpected summary

The Big Idea was that different projects would have different QA
infrastructure requirements, which would be satisfied by writing system
specific test harnesses.  So, for instance, we have a dejagnu specific
test harness in the libgcj source tree.

> * Repeated executions require knowing inner workings of
> various scripts

Again, this may be a result of our assumption that the core Mauve
infrastructure would be augmented by project specific infrastructure.

> * Integration of additional libraries difficult at best
> * Integration of VM specific tests also difficult
>  
> Solutions
>          
> * Change configure script to be installation oriented, similar for
> Makefile.am (started this already)
> * New script(s) for running mauve to compile, execute, report
> results (consider using dejagnu)
> 	* Specify java compiler at runtime
>         * Specify vm at runtime
>         * Specify temporary directory at runtime
> 	* Specify additional libraries/resources at runtime
> 	* Specify additional tests at runtime

Are you doing this for a specific system, or for stand-alone Mauve
usage?

> Basically all the cruft and gorp in configure.in, Makefile.am, choose,
> etc. gets done over.  The TAGS system is broken, it doesn't allow one to
> specify that a particular test is only valid for 1.1, 1.2, 1.3 and not
> 1.4+, essential to handle deprecated methods that eventually get
> removed.  I have no problem doing this work, my problem is all the
> people that depend on the current directory structure, build process,
> etc. that will scream if something is changed.  Anyway I have started
> the work, when I have a patch I'll let the list review.  Don't hold your
> breath, I'm slow sometimes.  :)

FWIW, I don't feel strongly about the stand-alone Mauve infrastructure
as long as the libgcj usage doesn't break (see
gcc/libjava/testsuite/libjava.mauve).

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: Mauve patches.

[C. Brian Jones]

[-- Attachment #1: Type: text/plain, Size: 3307 bytes --]

Thanks for your comments Anthony!

On Fri, 2004-04-16 at 16:23, Anthony Green wrote:
> On Sun, 2004-04-11 at 21:12, C. Brian Jones wrote:
> > * Cannot be installed (packaged, used repeatedly for various cases from
> > same install)
> 
> I'm not sure why you would want to "install" mauve.  I guess I'm too
> used to how we use Mauve with libgcj.

I want to be able to run it against gcj, gij, kissme, kaffe, sablevm,
jamvm, jdk, etc.  Not really all at once, just depending on what I'm
using at the time.  I don't think the clean, reconfigure, make dance is
appropriate for this task.

> > * No integrated pass/fail/expected/unexpected summary
> 
> The Big Idea was that different projects would have different QA
> infrastructure requirements, which would be satisfied by writing system
> specific test harnesses.  So, for instance, we have a dejagnu specific
> test harness in the libgcj source tree.

Nothing wrong with that, but it wouldn't hurt to provide something out
of the box would it?

> > * Repeated executions require knowing inner workings of
> > various scripts
> 
> Again, this may be a result of our assumption that the core Mauve
> infrastructure would be augmented by project specific infrastructure.

It's pretty nasty.  I have a feeling it turns some people away when it
isn't very clear how to set it up, run it, add or modify a test, and
re-run it.

> > * Integration of additional libraries difficult at best
> > * Integration of VM specific tests also difficult
> >  
> > Solutions
> >          
> > * Change configure script to be installation oriented, similar for
> > Makefile.am (started this already)
> > * New script(s) for running mauve to compile, execute, report
> > results (consider using dejagnu)
> > 	* Specify java compiler at runtime
> >         * Specify vm at runtime
> >         * Specify temporary directory at runtime
> > 	* Specify additional libraries/resources at runtime
> > 	* Specify additional tests at runtime
> 
> Are you doing this for a specific system, or for stand-alone Mauve
> usage?

The intention is for standalone use.  Although one could probably keep
the Makefile.am/configure as-is, it would clean things up considerably
to move such their current functionality into a re-usable script.

> > Basically all the cruft and gorp in configure.in, Makefile.am, choose,
> > etc. gets done over.  The TAGS system is broken, it doesn't allow one to
> > specify that a particular test is only valid for 1.1, 1.2, 1.3 and not
> > 1.4+, essential to handle deprecated methods that eventually get
> > removed.  I have no problem doing this work, my problem is all the
> > people that depend on the current directory structure, build process,
> > etc. that will scream if something is changed.  Anyway I have started
> > the work, when I have a patch I'll let the list review.  Don't hold your
> > breath, I'm slow sometimes.  :)
> 
> FWIW, I don't feel strongly about the stand-alone Mauve infrastructure
> as long as the libgcj usage doesn't break (see
> gcc/libjava/testsuite/libjava.mauve).

Right, I have a feeling that to do what I want I'd have to modify some
part of this though probably not a great deal as long as tests can still
be executed without installing.

Brian

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Mauve patches.

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 16 April 2004 00:56, you wrote:
> > > > > I hope you'll agree that its more important to have people
> > > > > creating patches and moving the project forward then to always
> > > > > have a 100% correct CVS. (problems can be fixed post-commit)
> > > >
> > > > No!
> > >
> > > would you care to elaborate on your position?
> >
> > Sure: "Problems should be fixed pre-commit."
>
> I agree. Mauve is actually used daily by people (me). And some people
> even use it in autobuilders/testers which are updated from CVS.

Hmm, I should have been more clear then. I naturally always will keep 
things compiling (one of the fixes I had was to get it compiling with suns 
Javac, for example).
I would never change the content of a class significantly without prior 
consent on the list.

The problems I 'expect' will be formatting things and other little things 
that I miss due to my different background. I put the "expect" between 
quotes because its not like I feel these things will happen; its just a 
saveguard for the rest of the team that if I commit something thats not up 
to spec; feel free to change it.

So I repeat my request for a cvs account..

Cheers!
- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAgULBCojCW6H2z/QRAiAXAJ9b232cutzP1a24L1iSRgn34I6pJQCffqAd
UMwMzP7qKpews57QPh0jN/4=
=Hd8X
-----END PGP SIGNATURE-----