sequential task in that the latter
follows the thread of execution, and only checks state to ensure
it can continue. This job's thread of execution passes onwards after the
cascade has been set up. This job will complete asynchronously once all
it's children have completed.
sequential does. The state behaviour is equivalent to the
WORST state operator, which is what is desired in most situations. A
stateOperator property may be added in future versions
if needed.
| cascadeOn | The state to continue the cascade on. |
| haltOn | The state to halt the cascade on. |
| jobs | The child jobs. |
| name | A name, can be any text. |
| stop | Read only view of the internal stop flag. |
| Example 1 | A cascade of two jobs. |
| Example 2 | Showing cascade being used with parallel. |
| Configured By | ATTRIBUTE |
| Access | READ_WRITE |
| Required | No, defaults to COMPLETE. |
The state to continue the cascade on.
| Configured By | ATTRIBUTE |
| Access | READ_WRITE |
| Required | No, defaults to FAILURE. |
The state to halt the cascade on.
| Configured By | ELEMENT |
| Access | WRITE_ONLY |
| Required | No, but pointless if missing. |
The child jobs.
| Configured By | ATTRIBUTE |
| Access | READ_WRITE |
| Required | No. |
A name, can be any text.
| Access | READ_ONLY |
Read only view of the internal stop flag. This flag is cleared with a reset.
A cascade of two jobs.
<oddjob>
<job>
<cascade>
<jobs>
<echo>This runs first.</echo>
<echo>Then this.</echo>
</jobs>
</cascade>
</job>
</oddjob>
Showing cascade being used with parallel. The cascade will
wait for the parallel job to finish before running the third job.
<oddjob>
<job>
<cascade>
<jobs>
<parallel>
<jobs>
<echo>Oranges could be first or second.</echo>
<echo>Pears could be first or second.</echo>
</jobs>
</parallel>
<echo>Apples are guaranteed to be third.</echo>
</jobs>
</cascade>
</job>
</oddjob>