Dees, Ian (GE Healthcare) wrote:
Since the <junit> task is actually forking the JVMs, I don't think that
putting the <junit> task in <parallel> will work. I'd have to put
multiple <junit>'s inside the <parallel>. Is there a more elegant way to
do this?
I suppose I could extend the <junit> task's forkMode to add a parallel.
-it would need a new mode. you'd also want to add a limit to the
parallelisation, ideally something that could be driven by the #of
cores, though as every user's config varies, that gets complex fast (and
I dont know a Java api call to get the count of real CPUs), then there's
memory/HDD limitations.
-Ive done <junit> in <parallel> to test SOAP clients against different
endpoints...each one was the same test hierarchy against a different
remote endpoint, with different jvm properties. a <presetdef> sets up
most of the run, then you run four copies in parallel with different
targets.
-the other use of the multiple CPUs is to set up VMWare/Xen images of
different platforms, and run builds in these. You need even more memory,
but can have something like hudson or luntbuild testing specific
projects, modules or branches in the repository while the developer
works on it.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
