Package com.xebialabs.xlrelease.domain

Class PluginTask

java.lang.Object
com.xebialabs.deployit.plugin.api.udm.base.BaseConfigurationItem
com.xebialabs.xlrelease.domain.PlanItem
com.xebialabs.xlrelease.domain.Task
com.xebialabs.xlrelease.domain.PluginTask
All Implemented Interfaces:
ConfigurationItem, Lockable, VisitableItem, Serializable, Comparable<BaseConfigurationItem>
@Metadata(label="Plugin Task", versioned=false, description="Task type contributed by an OSGi plugin bundle") public class PluginTask extends Task
The single compiled Task behind every task type contributed by an OSGi plugin bundle.

It is never subclassed - not by the host and not by plugin authors. A bundle declares a synthetic subtype of PluginTaskConfiguration instead, and this task carries an instance of it by containment. That is the same split CustomScriptTask has with PythonScript, and it is what keeps author-declared properties out of the namespace Task occupies.

Consequently every plugin task has the task type xlrelease.PluginTask; the type a release author picked is getConfiguration().getType(), which is also the key the host dispatches on when it looks for the TaskExecutorExtension that implements it. This mirrors every Jython task being xlrelease.CustomScriptTask.

See Also:

  • Field Details

    • PLUGIN_TASK_CONFIGURATION_PREFIX

      public static final String PLUGIN_TASK_CONFIGURATION_PREFIX
      Prefix for addressing a configuration property as a fully-qualified task property - used in variable mappings and output-property addressing, mirroring CustomScriptTask.PYTHON_SCRIPT_PREFIX. It is user-visible, so it is deliberately short and self-describing.
      See Also:

    • CONFIGURATION_PROPERTY

      public static final String CONFIGURATION_PROPERTY
      See Also:

  • Constructor Details

    • PluginTask

      public PluginTask()

  • Method Details

    • getConfiguration

      public PluginTaskConfiguration getConfiguration()

    • setConfiguration

      public void setConfiguration(PluginTaskConfiguration configuration)

    • isSuspended

      public boolean isSuspended()
      Whether the implementation suspended itself and expects to be re-entered - the analogue of CustomScriptTask.hasNextScriptToExecute(), and what makes the task stay IN_PROGRESS instead of completing.

    • hasScheduledResume

      public boolean hasScheduledResume()
      Suspended with a timer: re-enter after getResumeDelay() seconds.

    • isAwaitingSignal

      public boolean isAwaitingSignal()
      Suspended with no timer: re-entered only when something calls resumeTask.

    • suspendFor

      public void suspendFor(Integer delaySeconds)
      Records that the implementation asked to be re-entered after delaySeconds.
      Throws:
      IllegalArgumentException - if below one second, matching the bound CustomScriptTask.schedule(String, Integer) enforces on its interval and TaskExecutionResult.suspendFor enforces on its duration

    • awaitSignal

      public void awaitSignal()
      Records that the implementation is waiting for an external signal, with no timer.

    • resetSuspension

      public void resetSuspension()
      Clears the suspension. Must happen on every terminal or restarting transition, or a stale marker would make the next execution look like a resume.

    • getResumeDelay

      public Integer getResumeDelay()

    • setResumeDelay

      public void setResumeDelay(Integer resumeDelay)

    • setSuspended

      public void setSuspended(boolean suspended)

    • fail

      public Changes fail(String targetId, String failReason, User user, boolean fromAbort)
      Mirrors CustomScriptTask.fail: failing an in-flight task must clear the suspension, or an abort of a suspended task would leave a marker behind. Job cancellation itself is WorkManager.abortJobByTaskId's job, called separately by the abort path - not this CI's.
      Overrides:
      fail in class Task

    • retry

      public Changes retry(String targetId)
      Mirrors CustomScriptTask.retry: a retried task starts from a clean slate.
      Overrides:
      retry in class Task

    • execute

      protected Changes execute(String targetId, TaskStartOrRetryOperation operation)
      Mirrors ContainerTask/NotificationTask/CreateReleaseTask's override: super.execute may defer the transition (blackout, unbound variables, facet/precondition checks), so the ExecuteTaskAction post-action - which is what actually dispatches to PluginTaskExecutor and submits the PluginTaskJob - is only added once the task has genuinely reached IN_PROGRESS. Without this override the task transitions to IN_PROGRESS in the UI but nothing ever runs the extension: Task.execute has no type-generic way to know a plugin task needs dispatching, since every other task family opts in the same way.
      Overrides:
      execute in class Task

    • freezeVariablesInCustomFields

      public Set<String> freezeVariablesInCustomFields(Map<String,ValueWithInterpolation> variables, Map<String,String> passwordVariables, Changes changes, boolean freezeEvenIfUnresolved)
      Interpolates release variables into the configuration's input properties, mirroring CustomScriptTask.freezeVariablesInCustomFields minus its Jython-script-specific special cases (there is no script property to exempt here).
      Overrides:
      freezeVariablesInCustomFields in class Task

    • shouldFreezeVariableMapping

      protected boolean shouldFreezeVariableMapping(CiProperty property)
      Output properties are produced by execution, so they are not frozen from variables - same rule as CustomScriptTask.
      Overrides:
      shouldFreezeVariableMapping in class Task