Steve,
Sorry for the delay.
>>I guess if JBoss shows the problem, then yes, some kind of external
control makes sense. But having one big
>>switch that suddenly flips the response processing over is scary, very
scary, because Execute() is used everywhere,
>>even in things like Java.
Actually the Jboss test suite is driving our suggestions. I
agree having one big switch is scary because Execute() is use everywhere
and I have be looking for other options. Does this mean we should be
thinking about adding a task option/property? Something like
"successStatus=<value>", the default would be ZERO as success for all
platforms. The user could specific a successful status code. For
example most of Java's JCK tests return "95" for a successful test, or
96, 97... For any failures. Of course this doesn't match today's
isFailure method, so ant would deem the test a failure if it returned a
"95", 96 or 97. Having zero as the default would also match existing
documentation for Java,javadoc tasks:
void setFailonerror(boolean b)
Should the build process fail if javadoc fails (as indicated
by a non zero return code)?
>>Of course, we do have a little problem here. Execute.isFailure() is
>>static. Whether its configurable by a project property or by a
>>per-instance option, that test is now bound to a project and perhaps
an
>>Execute instance. So a static variable is wrong. Really we need an
>>Execute.isFailure() that looks at the exit value and does the right
thing.
Yes, I agree we have a little problem because Execute.isFailure() is
static. However if we where to use something like
"successStatus=<value>" we could have another static method
"Execute.isFailure(int exitValue, int succcessValue)". This way we
could also check for the "-1 as the return code which burns them on
SYSV" issue as well.
Best Regards,
Powell
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
