Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 28049 invoked by uid 500); 12 Aug 2003 16:00:52 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 28033 invoked from network); 12 Aug 2003 16:00:51 -0000 Received: from dns2.digitalglobe.com (205.166.175.35) by daedalus.apache.org with SMTP; 12 Aug 2003 16:00:51 -0000 Received: from comail.digitalglobe.com (comail.digitalglobe.com [10.10.42.3]) by dns2.digitalglobe.com (8.12.6/8.12.5) with ESMTP id h7CG0qxv077957 for ; Tue, 12 Aug 2003 10:00:53 -0600 (MDT) (envelope-from ferret@frii.com) Received: from pclnxbsnyder.digitalglobe.com ([10.10.30.169]) by comail.digitalglobe.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id QXAGK99Y; Tue, 12 Aug 2003 10:00:52 -0600 Date: Tue, 12 Aug 2003 16:00:52 +0000 (GMT) From: Bruce Snyder X-X-Sender: bsnyder@pclnxbsnyder.digitalglobe.com To: geronimo-dev@incubator.apache.org Subject: Re: [Testing] Testing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This one time, at band camp, Alex Blewitt said: AB>I think you'll end up with a situation where a spec-test developer will AB>just put in the section-number, since that's essentially what AB>highlights it. Also, if the section is prefixed with a document name AB>(J2EE_1.4-4.2.7) then you can pretty much get rid of everything else. AB> AB>I agree that having everything self-contained is good, but I can't see AB>developers caring about typing in chapter-name and section-name each AB>time they need a test. It should be relatively easy to put the sections AB>in a properties file listing each of them and just do a lookup (using AB>J2EE_1.4-4.2.7 as a key in a properties file) AB> AB> : AB>J2EE_1.4-4.2.7=J2EE 1.4: Transaction Management (Transactional JDBC AB>Technology Support) AB> : AB>J2EE_1.4-6.17=J2EE 1.4: Java Management Extensions AB> : Another very good point which has made me rethink the idea completely. How about a cross reference which contains all the metadata? AB>> I agree that there needs to be a measuring stick of sorts for AB>> determining AB>> how much further we need to go. But the idea is that the inclusion of AB>> the AB>> section-number adds the ability to view a report and easily see gaps in AB>> the section numbers. I'll be honest that I don't care to volunteer for AB>> going through each spec and making a list of the tests. Maybe someone AB>> else is interested in performing this task. AB> AB>I know the feeling :-) AB> AB>Anyway, instead of having to type chapter-title-section-name each time, AB>I've munged the J2EE 1.4 ToC and prepared the attached properties file. AB>Should save developers having to type in the lot each time. AB> AB>The Doclet can then weave the section number in and lookup entries in AB>the keyset. Should also be able to do sufficient sorting so that it can AB>order things by chapter and title anyway, since they're encoded in the AB>key itself. Right idea, but what about the rest of the metadata? I don't think that parsing a TOC and a metadata file is the right approach. I vote for housing it all together in an XML file ala JMSCTS (http://jmscts.sf.net/) as suggested by Tim Anderson in the next message in this thread. Bruce -- perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E