# 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.

Each task has the following properties:

- 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.

Each task supports the following operations:

- 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

Copyright (c) 2014 Eike Stepper (Loehne, Germany) and others.
All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v2.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v20.html