That looks totally cool, I think that's definately a good way to be handling things. Has anyone got documentation on the go for the junit stuff yet?
-----Original Message----- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 08 August 2000 12:23 To: [EMAIL PROTECTED] Subject: Re: [PATCH] Pattern based Junit tests >>>>> "JM" == Jeff Martin <[EMAIL PROTECTED]> writes: JM> This is a patch which adds a new subtask called batchtest to the JM> junit task. I'm in the course of rewriting most of the JUnit stuff at the moment, I'm going to include the functionality but will base it on the include/exclude mechanism like the one for filesets. I.e. <batchtest dir="${java.src}> <include name="**/test_*.java" /> </batchtest> is this OK? Other things I'm going to change: * add if and unless attributes to test (and possibly batchtest?). Should behave like the ones for targets and include/exclude. * remove the string "default" from the attributes of JUnit. * remove printxml everywhere (see <formatter> below). Remove printsummary from <test>. * remove defaultoutfile. All this does is hand a default filename to the XML Formatter - which we should do anyway if the user want XML output and doesn't specify a filename. * add a nested <formatter> tag, both to <junit> as well as to <test> (and <batchtest>?). <junit> <formatter type="xml"> </junit> will do the same as defaultprintxml did. <junit> <formatter type="plain"> </junit> will produce plain text files with the same content the XML files had. <junit> <formatter classname="my.own.Formatter" /> </junit> will use my.own.Formatter, which must implement org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter. What do you think of these ideas? Did I remove something that will break your setup - and doesn't provide a different way to achieve the same? Stefan
