Class PluginTaskViewConverter

java.lang.Object
com.xebialabs.xlrelease.views.converters.BaseTaskViewConverter<com.xebialabs.xlrelease.domain.PluginTask>
com.xebialabs.xlrelease.domain.tasks.plugin.PluginTaskViewConverter
All Implemented Interfaces:
TaskViewConverter<com.xebialabs.xlrelease.domain.PluginTask>, PlanItemConverter

@Component public class PluginTaskViewConverter extends BaseTaskViewConverter<com.xebialabs.xlrelease.domain.PluginTask>
REST/UI view conversion for plugin tasks, mirroring CustomScriptTaskViewConverter.

Why this reuses scriptDefinitionType

Every plugin task has task type xlrelease.PluginTask, so the view has to carry the configuration type separately or the UI cannot tell an acme.Deploy from an acme.TriggerBuild. TaskFullView already has exactly one field for "the definition type to render this task by, which differs from type": scriptDefinitionType.

Reusing it was checked against the frontend rather than assumed. The field is never used as a "this is a Jython task" discriminator: task.helper.ts's hasScriptDefinition(task) is a presence check on the field itself, and getTaskDefinition uses it to mean "look the definition up by this instead of by task.type" - which is precisely what a plugin task needs. Consequently plugin tasks render with their own display name, icon and properties with no frontend change and no new REST field. The name is historical; the semantics are not script-specific.

  • Constructor Details

    • PluginTaskViewConverter

      @Autowired public PluginTaskViewConverter(com.xebialabs.xlrelease.repository.ConfigurationRepository configurationRepository)
  • Method Details