The Workflow

Each goal of the plugin has its own default workflow which is a fixed part of the plugin. But if you need to customize the goal execution you are free to override this default workflow and specify your own one. Overriding the default workflow is f.i. described on the Usage Page of this Wiki.

Now with version 2.2.0 the workflow format has changed a bit but is fully compatible with previous versions. You can find the full documentation here. Here is a short list of the available concepts:

• # some text: This is a comment line.
• some-step-id: Each line stands for a processing step execution.
• parallel {: Opens a block of parallel step executions. Each nested line stands for a step execution. It is required to close this block with a single line containing } only.
• step[1]: The id nested in brackets is called qualifier. Qualifiers are used to distinguish multiple executions of processing steps.
• step { or step[qualifier] {: (New in 2.2.0) Opens a data assignment block for processing steps. There you can assign default processing data or default rollback data to processing hooks. This block must be closed by } The following elements are nestable:
  • data=...: This assigns default processing data to the step execution which can be overridden when calling the goal.
  • rollbackData=...: This assigns default rollback data to the step execution which can be overridden when calling the goal.
• try {: (New in 2.2.0) Opens the try block. This must be the first statement of the workflow descriptor. This block must be closed by the finally block. Only one try-finally block is allowed per descriptor.
• } finally {: (New in 2.2.0) Closes the try block and opens the finally block. The finally block is guaranteed to be executed, even if the try workflow fails. In case of a try-failure the try workflow will be rolled back before the finally workflow starts its execution. The finally block must be the last statement of the workflow needs to be closed by a line containing }

Example

The following example contains an extended workflow which tries the execution of the release workflow with an exec hook that has default execution and rollback data assigned. The finally block executes another exec hook doing something else.

try {
  storeScmRevision
  checkProjectVersions
  checkParentVersions
  checkDependencies
  checkPlugins
  checkPluginDependencies
  prepareVersions
  checkAether
  setReleaseVersions
  addSpyPlugin
  buildReleaseArtifacts
  exec[copy-artifact] {
    data=mkdir /var/local/share/releases/@{project.version}, cp -r target/@{project.artifactId}-@{project.version}.jar /var/local/share/releases/@{project.version}/@{project.artifactId}.jar
    rollbackData=rm -fr /var/local/share/releases/@{project.version}
  }
  removeSpyPlugin
  checkForScmChanges
  tagScm
  detectReleaseArtifacts
  setDevVersion
  installArtifacts
  deployArtifacts
} finally {
  exec[inform-user] {
    data=echo "Check your release artifacts!"
  }
}