Geir, I support your point - a developer who resolves an intermittent issue needs a painless way to check his resolution.
I see two ways to implement it: * Automatically generate a build script: Egor posted me a feedback that it is not quite readable approach. * Use <for> ant-contrib task: this adds ant-contrib dependency to the class library build system. * Make a clone from <junit> task: this adds a dependency from ANT source base. All, Before starting a patch discussion let me ask which of three do you think is a better approach? -- Thank you, Alexei BTW, this ugly hack produced new reliability results which are available at http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM#reliability. On 11/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Alexei Fedotov wrote: > Tatiana, > I cannot stop myself from thinking about your wonderful scripts. > > 1. > Looking at http://issues.apache.org/jira/browse/HARMONY-2282 I > realized that in case of absence of DRLVM crash it would be quite > useful to know if the bug is reproducible with J9. > > Failures on two different VMs convinces test authors to look in their > tests once again to decide how valid they are. So if it wasn't > difficult to launch your script for J9, this would be quite useful. +1 > > 2. The second thing which comes into my mind is speeding up test runs > by hacking build.xml files: > > perl -i -e 'undef $/; $_ = <>; s/(<batchtest.*?<\/batchtest>)/$1 x > 50/es; print' modules/*/build.xml > > You can revert build files later using svn revert modules/*/build.xml. > I wonder if we can set forkmode to vary a reliability load from > running all tests in the same JVM to running each test separately. Ugh. :) How about finding a way to incorporate this formally into the build scripts, so it can simply be parameterized? geir
