ExecTask returnProperty

[stefan.oestreicher@…]

It would be nice if ExecTask had an option to store the exit code of the executed program in a property so it can be used later on. This is especially useful when you need to call a program that doesn't strictly adhere to the convention of always returning 0 for a successfull run and you need to cancel the build if it failed, so you can't use the "checkreturn" attribute. I think it would be consistent to use an attribute called "returnProperty" (like PhpEvalTask does) for this purpose.

A more elaborate solution would be to allow for two attributes, lets call them "fail" and "failnot" which take a list of return values on which to fail or not to fail.

Consider this example: <exec cmd="someprogram -x -y -z" failnot="0,1" failmsg="Someprogram made a boo boo, aborting build" />

This snippet should fail if someprogram returns anything else than 0 or 1.

<exec cmd="someprogram -x -y -z" fail="99" failmsg="Someprogram made a severe boo boo, aborting build" />

This snippet would only fail if the someprogram returned 99.

[hans]

I like the idea of returnProperty; I'm not sure that failing makes sense inside this task, though. (It would be really easy to just have a condition that causes a failure if a specific property is set or not 0, etc.)

[hans]

(In [334]) Refs #203 - Added returnProperty to exec task.

[hans]

Ok, in r334, the returnProperty attribute was added; this allows you to capture the return value from the exec() call and perform custom logic. For example:

<exec cmd="someprog -x -y -z" returnProperty="app.return"/>
<if>
 <not>
  <equals arg1="${app.return}" arg2="0"/>
 </not>
 <then>
  <fail msg="someprog failed!"/>
 </then>
</if>

As I discovered when diving into this task, there is also a checkreturn attribute, which will cause a BuildException if the program does not have a return code of 0.

e.g.

<exec cmd="someprog -x -y -z" checkreturn="true"/>

While that doesn't allow you to customize the message, I think it provides a nice shorthand for ensuring that a program exits nicely. So, I'm going to close this as fixed, since I think all the functionality in this ticket is possible now using the exec task. If there's a convincing reason to implement the failmsg, etc. we can revisit/reopen. Thanks!