From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13713 invoked by alias); 28 Apr 2004 21:56:02 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 13705 invoked from network); 28 Apr 2004 21:56:01 -0000 Received: from unknown (HELO smtpq3.home.nl) (213.51.128.198) by sources.redhat.com with SMTP; 28 Apr 2004 21:56:01 -0000 Received: from [213.51.128.135] (port=59464 helo=smtp4.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1BIx28-00012s-G1; Wed, 28 Apr 2004 23:56:00 +0200 Received: from cc68231-a.ensch1.ov.home.nl ([212.120.112.227]:33867 helo=dumas.thomas.planescape.com) by smtp4.home.nl with esmtp (Exim 4.30) id 1BIx2F-0000d5-Ao; Wed, 28 Apr 2004 23:56:07 +0200 From: Thomas Zander To: mauve-discuss@sources.redhat.com Subject: Re: Eclipse and Classpath Date: Wed, 28 Apr 2004 21:56:00 -0000 User-Agent: KMail/1.6.2 Cc: Jeff Sturm , Michael Koch , GNU Classpath Project References: <877jvzhoef.fsf@fleche.redhat.com> In-Reply-To: <877jvzhoef.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200404282354.50797.zander@javalobby.org> X-AtHome-MailScanner-Information: Please contact support@home.nl for more information X-AtHome-MailScanner: Found to be clean X-SW-Source: 2004-q2/txt/msg00053.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 April 2004 21:51, Tom Tromey wrote: > Jeff> (What about Mauve? Much of Eclipse's usefulness for us comes from > Jeff> interactively running the test suite so we get a very quick > Jeff> edit/compile/test/debug cycle. But eclipse only knows about > junit-style Jeff> tests, not the gnu.testlet classes in Mauve.) > > I think Graydon changed Mauve to use JUnit at one point, but it never > went in. I think there was some confusion about some points I made. > > It's time to revisit this (various folks pointed this out to me at the > recent RH meeting). IMO anything that makes Mauve easier to hack is a > good thing. My only real requirement is that we still be able to run > the gcj test suite; I don't think there is any substantial problem > here. IIRC the biggest problem with using JUnit is that it depends of rather=20 advanced JVM features; like reflection. Its technically possible to have a mauve test case extend a=20 mauve-base-class which can be changed on run-time (probably using a=20 singleton) to either use the very-simple-mauve test framework, or the=20 JUnit ones. Using a facade pattern in that baseclass. Its still needed to call each test in one long test() method if you want to= =20 use the mauve version, but other then that it would integrate with JUnit=20 quite nicely. Naturally all tests will need to be refactored to do this.. - - extending a base class instead of implementing Testlet - - using the assertTrue() style checking instead of the check() versions. Thoughts? - --=20 Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAkCgpCojCW6H2z/QRAp0LAKCxgcsGMzDHdMPDDVDTPUBNPCQjGgCgkU8j qAf1uGZxFCYoTpSJreFpitY=3D =3DnRwQ -----END PGP SIGNATURE-----