This constant is a value for embed flags when reporting output build artifacts.

This value causes the artifact to be always written in the build trace. It overrides the user preference of artifact embedding. Generally, this value should be rarely used, only if the user explicitly specifies it for the build task.

The associated artifact will be embedded in the build trace if the user configures the build trace to embed artifacts. (-trace-artifacts-embed command line parameter)

This value can be combined with any other ARTIFACT_EMBED_* constant.

Specifying this flag will cause the build trace to encrypt the contents of the output artifact with an user specified password.

If the user haven't specified a password for the build trace, the contents of the artifact are not written in the build trace at all, and instead a note is persisted telling them to specify a password.

This constant is a value for embed flags when reporting output build artifacts.

Configuration tasks don't perform long running or complex build operations, but only retrieve some configuration object based on the input parameters. These configuration objects are usually inputs to other tasks to configure their behaviour.

Configuration tasks are may be omitted in the build trace viewer.

External tasks are tasks that generally perform no other operation but directly invoke another task. That is, calling Task.run(TaskContext), and not starting them through TaskContext.

Generally, external tasks are only reported by the build system or script language implementation when they bootstrap the actually invoked tasks. Under normal circumstances, you don't classify your build tasks as being external.

The build trace viewer may decide to omit external tasks from the view in some cases.

Frontend tasks are responsible for parsing the input parameters of a given task and starting a worker task that performs the actual build operation.

This classification is similar to meta, but may be differentiated by the build trace if necessary.

Frontent tasks are generally omitted in the build trace viewer.

Meta tasks are considered to contribute little or nothing to the build results and serve only as a configuration or control flow task for the build execution.

Generally, meta tasks spend most of their time as waiting for other tasks, or performing other task management related operations.

Meta tasks are generally omitted in the build trace viewer.

The tasks which are classified as transformation tasks serve the purpose of transforming various information in other form. In general, they are similar to configuration tasks, but they can perform longer running operations in cases where they need to.

Some examples for transformation tasks are:

• Tasks which extract some files from an archive.
• Task that constructs a file tree in the required format based on some inputs.
• Tasks that convert files or other information to a different encoding or format. (E.g. convert JSON to XML)

Transformation tasks are usually not displayed in the build trace, unless they throw exceptions or emit warnings.

Note that tasks that derive resources based on their inputs, or perform meaningful operations on them are recommended to be classified as worker tasks. E.g. a task that creates a ZIP archive based on its inputs should be classfied as worker task. However, if the ZIP is created for the sole purpose of consuming by another task, then it should be a transformation task.

Worker tasks are the ones that perform long running build operations. They are usually computationally heavy, and contribute to the actual build outputs.

E.g. compiling sources, downloading files, or other longer operations.

Generally, worker tasks provide meaningful performance information for the developer.

This constant can be used with custom value setting functions such as setValues(Map<?, ?>, String).

The values associated with this category are displayed alongside other build environment related information.

When values are set for this category, the values will be associated with the build environment of the caller. If the values are set on a build cluster, then they will be associated with that build environment instead of the coordinator environment.

In general values that are independent from the current build should be set with this category.

Note that you should not set values when the environment properties are being computed (see getCurrentValue). As they can be cached by the build environment, subsequent builds may not record these values.
To set build trace values related to environment properties, implement the TraceContributorEnvironmentProperty interface in your EnvironmentProperty. The contributeBuildTraceInformation method will be automatically called for the property to contribute its values.

This constant can be used with custom value setting functions such as setValues(Map<?, ?>, String).

The values associated with this category are be displayed alongside the task informations in the build trace. This includes the views where task details can be examined by the user.

If the values are set from an inner task, the values will be displayed for the calling inner task rather than the enclosing task.