RE: Question about property name

["Hazzard, Powell" <Po...@hp.com>]

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org