From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26105 invoked by alias); 9 Feb 2005 09:25:18 -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 25999 invoked from network); 9 Feb 2005 09:25:06 -0000 Received: from unknown (HELO lembu.sumatrasoftware.com) (62.177.154.238) by sourceware.org with SMTP; 9 Feb 2005 09:25:06 -0000 Content-class: urn:content-classes:message Subject: RE: New runner MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 09 Feb 2005 09:25:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Jeroen Frijters" To: "Thomas Zander" , X-SW-Source: 2005-q1/txt/msg00024.txt.bz2 Thomas Zander wrote: > Hi, Jeroen. Thanks for your reply. > I've just looked into this; when I delete the config and the > SimpleTestHarness I get compile errors in (only) 9 tests. > The following are easy to fix and run correctly with some=20 > modifications > (read: removal of the cast): > gnu/testlet/java/io/FileDescriptor/jdk11.java > gnu/testlet/java/io/FileReader/jdk11.java > gnu/testlet/java/io/FileWriter/jdk11.java > gnu/testlet/java/io/RandomAccessFile/jdk11.java >=20 > These are a bit more difficult; but I believe them to be=20 > broken by design or not usable for a 'java -jar' kind of > test anyway. > I'll be more specific: > These 4 tests each test some socket stuff based completely on the > assumtion that there is someone (an smtp host) listening on a > pre-configured host/port. This is quite an assumtion that is not very > usable in the proposed (portable) test-jar. > gnu/testlet/java/net/Socket/SocketTest.java > gnu/testlet/java/net/Socket/jdk12.java > gnu/testlet/java/net/Socket/jdk13.java > gnu/testlet/java/net/Socket/jdk14.java I don't think they're inherently unusable from a jar, I'd like to see a gnu.testlet.config version that reads the settings from a properties file (or whatever) instead of hardcoding them in the auto dance. > The following test tests things like being able to open a=20 > file we ship in mauve (in the same package) and other stuff thats > really really basic. (like File.seperator) Quite useless to test > in an environment that is shipped in a jar :-) > gnu/testlet/java/io/File/jdk11.java This is more tricky to handle, but hopefully we can figure out a way to get this test in as well. Regards, Jeroen