Tasks

A setup task is the fine-grained unit of work in the overall setup process. A task is declarative in nature, i.e., it describes what needs to be achieved rather than how it's achieved. Each task is contained within a scope. The overall setup process involves gathering tasks from various scopes and then performing those tasks.

• An optional ID attribute. The value of this attribute, if present, must be unique within the containing resource. If the task has an ID, a variable is inferred for each populated String-typed attribute of that task. This variable behaves as if it were logically contained just before the task in the task's container.

An excluded triggers attribute that specifies the triggers for which that task is not applicable. This affects which tasks will be gathered. Most task implementations exclude the bootstrap trigger because they must execute within a running product where the task implementation along with the supporting infrastructure are installed. As such, task implementations hard-code the permissible triggers and task authors can further exclude triggers from those that are permissible. In the end, by logical exclusion, this induces an overall set of allowed triggers.

• A disabled attribute that specifies whether or not the task should be gathered.
• An optional restrictions reference that specifies the set of scopes to which the task inclusively applies. TODO
• Both a predecessors references and a successors reference, that specify that tasks that must be performed, respectively, before or after, the task itself is performed. Furthermore, a task has an intrinsic priority that is determined by the task implementor. All these properties affect the order in which tasks are performed.

• Logic for determining whether the task needs to perform as well the logic for performing the task. The determination of whether that the task needs to perform is influenced by the trigger, i.e., it affects how detailed will be the analysis for determining whether the task needs to be performed with the general goal being to perform only those tasks strictly needed for the startup trigger. This behavior is documented on a per-task basis.
• A task, in general, can be overridden by other tasks during the process of gathering tasks. Which tasks are overridden by which other tasks, and how that override merges two tasks into a single combined task is specific to each task implementation and is therefore documented on a per-task basis. A task implement supports overrides by yielding a so called override token. Two tasks that yield equal override tokens are merged during the initial task gathering phase.
• A task, in general, can be consolidated. At the end of the task gathering phase, each task is consolidated to optimize its representation in preparation before the task is performed.

1  Trigger

There are three types of triggers:

• Bootstrap applies when using the installer wizard.
• Startup applies when a product is first launched, automated task performance is enabled, and there are tasks that need to be performed, at which point the execution wizard will be opened on the progressPage page.
• Manual applies when invoking the project wizard or directly invoking execution wizard.

Each task specifies its valid triggers determining whether that task is filtered when tasks are gathered.

2  Variable Task

3  Compound Task

4  P2 Task

5  Targlet Task