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:
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.
disabled
attribute that specifies whether or not the task should be gathered.
restrictions
reference
that specifies the set of scopes to which the task inclusively applies.
TODO
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:
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.
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.
consolidated
.
At the end of the task gathering phase,
each task is consolidated to optimize its representation in preparation before the task is performed.
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.