anchor.diff:  
   Thanks to our in-house users and to the developers of the many fine
   open source libraries we're able to use, including but not limited to
  -Oozie, Hadoop, Jetty, Rhino, Joda, Jackson, and Gradle.
  +Oozie, Hadoop, Jetty, Rhino, Joda, Jackson, Quartz, and Gradle.
  
positive.code: [options="header"]
  |===
  |State|Action
  |WAITING|Call the workflow's trigger to determine whether the slot is ready.  If the trigger signals readyness, put the slot into the READY state.  If the slot has been waiting for too long, put the slot into the WAIT_TIMEOUT state.  Otherwise, keep the slot in the WAITING state.
  |READY|Pass the slot as a candidate for scheduling to the workflow's scheduling strategy.  If the strategy chooses to execute the slot, submit it to Oozie, and put it into the RUNNING state.  Otherwise, keep the slot in the READY state.
  |RUNNING|Ask Oozie for the status of the execution.  If the slot is still executing, keep it in the RUNNING state.    If the slot has succeeded, put it into the SUCCESS state.  If the slot has failed, but there are retries left, put the slot into the WAITING state again.  If the slot has failed, and there are no more retries left, put the slot into the FAILURE state.
  |SUCCESS|Do nothing.
  
negative.code: celos.cronSchedule("0 0 5 * * ?");
  ....
  
  Another type of schedule is <<celos.dependentSchedule>>, which makes a
  workflow use the same schedule as another workflow.  This is useful
  for setting up a downstream workflow that tracks an upstream workflow,
  without having to duplicate the schedule definition.
  
  ==== Triggers
  
  For each slot of a workflow, a trigger is used to determine whether
  