This method works the same way as SakerDirectory.add(SakerFile), but returns a reference to the argument file. It is mostly useful when designing tasks for remote execution, as the files need to be transferred to the coordinator machine, therefore the actually added file to the directory might be different than the file passed as parameter. See SakerDirectory.add(SakerFile) documentation for more info.

This method can be called from both remote and non-remote executed tasks.

This method works the same way as SakerDirectory.addIfAbsent(SakerFile), but returns the reference to the argument file. It is mostly useful when designing tasks for remote execution, as the files need to be transferred to the coordinator machine, therefore the actually added file to the directory might be different than the file passed as parameter. See SakerDirectory.addIfAbsent(SakerFile) documentation for more info.

This method can be called from both remote and non-remote executed tasks.

This method works the same way as SakerDirectory.addOverwriteIfNotDirectory(SakerFile), but returns the reference to the argument file. It is mostly useful when designing tasks for remote execution, as the files need to be transferred to the coordinator machine, therefore the actually added file to the directory might be different than the file passed as parameter. See SakerDirectory.addOverwriteIfNotDirectory(SakerFile) documentation for more info.

This method can be called from both remote and non-remote executed tasks.

This method can be used to perform multiple operations in a single call. The method will invalidate the contents at the given path key and create a provider path file for the given path key. The created SakerFile is the added to the argument directory, and then syncronized.

Calling this method can be useful to batch the above operations in a single call. It is usually useful when you invoke an external process that produces a result file and want to add it to the build system file hierarchy.

This method doesn't report the argument as dependency.

Important: Calling this method will trigger the computation of file deltas as it uses TaskContext.getPreviousFileAdditionDependency(FileCollectionStrategy) to avoid redundant computations.

This method is the same as:

 collectionstrategy.collectFiles(taskcontext);
 

When designing tasks for remote execution, it is recommended to call this method instead invoking FileCollectionStrategy.collectFiles(ExecutionDirectoryContext, TaskDirectoryContext) directly.

For correct incremental operation tasks should not forget to report the dependencies as well. Consider calling collectFilesReportInputFileAndAdditionDependency(Object, FileCollectionStrategy) instead of this function.

This method collects the files for all the addition dependencies, and aggregates them into a single result map.

This method doesn't report input file dependency to the collected files.

Important: Calling this method will trigger the computation of file deltas as it uses TaskContext.getPreviousFileAdditionDependency(FileCollectionStrategy) to avoid redundant computations.

This method collects the files for all the addition dependencies, and aggregates them into a single result map.

This method collects the files for the specified addition dependency, reports the addition dependency, and reports the input dependencies for the collected files with their respective content descriptors.

Important: Calling this method will trigger the computation of file deltas as it uses TaskContext.getPreviousFileAdditionDependency(FileCollectionStrategy) to avoid redundant computations.

This method can be used to include files from a given file system in the build. The resulting file needs to be added to a SakerDirectory to be included in the in-memory hierarchy.

If the file at the given path is a directory, a SakerDirectory instance will be returned that contains all the files which are present in the given directory. (The directory may be lazily populated.)

Note that we recommend using createProviderPathFile(String, ProviderHolderPathKey, ContentDescriptor) when when creating SakerFiles for externally modified files. You should specify your own content descriptor for the modified file as in case where the file modification times are used to detect file changes, some changes may be unnoticed on file systems that have larger granularity. (E.g. if the file modification times are stored as seconds.)

The file represented with the given path must be a file, not a directory.

The argument content descriptor will be associated with the current contents of the file system at the given path. This means that unless some other agent modifies the contents at the given path, calling SakerFile.getContentDescriptor() will return the passed argument for the returned file.

This method can be used to include files from a given file system in the build. The resulting file needs to be added to a SakerDirectory to be included in the in-memory hierarchy.

The name of the file is the same as the name of the argument path.

This method is the same as:

 createProviderPathFile(pathkey.getPath().getFileName(), pathkey)
 

The method works the same way as createProviderPathFile(String, ProviderHolderPathKey, ContentDescriptor), but also associated the specified posix file permissions with the file.

The result file will return the argument posix file permissions from its SakerFile.getPosixFilePermissions() method.

It is not required for the underlying filesystem to support posix file permissions.

Note that the argument content descriptor should reflect the specified posix file permissions as well. It is recommended to use PosixFilePermissionsDelegateContentDescriptor.

Calling this method might implicitly synchronize the file to its real location, or to some other cache location when remote execution is used.

The resulting map is mapped by the file names of the children.

Calling this method might implicitly synchronize the file to its real location, or to some other cache location when remote execution is used.

The method works like TaskContext.invalidate(PathKey), but also instructs the build system to track the posix file permissions of the specified file. This will cause the file returned from createProviderPathFile(String, ProviderHolderPathKey) to have its SakerFile.getPosixFilePermissions() filled.

This method works only if the argument file resides on a filesystem that supports posix file permissions. Otherwise this method works the same way as TaskContext.invalidate(PathKey) without taking posix file permissions into account.

The method will resolve the specified path to a directory and execute the mirroring.

If the file doesn't exist, or not a directory, an exception is thrown.

The method will resolve the specified path to a file and execute the mirroring.

If the file doesn't exist, or is a directory, an exception is thrown.

The method works the same way as mirrorFileAtPath(SakerPath), but returns the content descriptor of the mirrored file.

Calling this method might implicitly synchronize the file to its real location, or to some other cache location when remote execution is used.

Calling this method might implicitly synchronize the file to its real location, or to some other cache location when remote execution is used.

This method works the same way as TaskContext.reportIgnoredException(ExceptionView), but takes care of converting the exception to an appropriate ExceptionView.

Each path-content descriptor pair will be reported as an input dependency.

See TaskContext.reportInputFileDependency(Object, SakerPath, ContentDescriptor).

Each path-content descriptor pair will be reported as an output dependency.

See TaskContext.reportOutputFileDependency(Object, SakerPath, ContentDescriptor).

If the path is relative, it will be resolved against the current task working directory.

If it is absolute, the execution root directories will be used as a base of resolution.

The path names are interpreted as if they were relative compared to the base directory.

This method doesn't overwrite the already existing file at the path if it's not a directory.

If the path is relative, it will be resolved against the current task working directory.

If it is absolute, the execution root directories will be used as a base of resolution.

If the path is relative, it will be resolved against the current task working directory.

If it is absolute, the execution root directories will be used as a base of resolution.

This method doesn't overwrite the already existing file at the path if it's not a directory.

If the path is relative, it will be resolved against the current task working directory.

If it is absolute, the execution root directories will be used as a base of resolution.

This method doesn't overwrite the already existing file at the path if it's not a directory.

The path names are interpreted as if they were relative compared to the base directory.

The path names are interpreted as if they were relative compared to the base directory.

This method doesn't overwrite the already existing file at the path if it's not a directory.

The path names are interpreted as if they were relative compared to the base directory.

If the path is relative, it will be resolved against the current task working directory.

If it is absolute, the execution root directories will be used as a base of resolution.

The path names are interpreted as if they were relative compared to the base directory.

This method is similar to runTaskResult(TaskIdentifier, TaskFactory<R>, TaskExecutionParameters), but doesn't add a dependency for the task, and returns a TaskFuture instance to the caller.

A task dependency will be added for the started task with the same rules as in TaskContext.getTaskResult(TaskIdentifier).

This method returns no result.

This method returns no result.

This function starts every task with the parameters specified by each launch arguments.

This function works the same way as if startTask(TaskLaunchArguments<?>) was called for each element in the argument.

This function returns void, to retrieve the futures for the started tasks as well, use startTasksFuture(Iterable<? extends TaskLaunchArguments<?>>).

The started tasks will use the default execution parameters.

This function works the same way as startTasks(Map<? extends TaskIdentifier, ? extends TaskFactory<?>>, TaskExecutionParameters) with null execution parameters.

The passed execution parameters will be used for each started task. If null, the default parameters will be used.

This function works the same way as if startTaskFuture(TaskLaunchArguments<R>) was called for each element in the argument.

The returned list of task futures will have the same order as the argument iterable.

This method synchronizes the contents of the source path file to the target path.

If the source file is a file, its contents will be updated to the target path. If a file already exists at the target path, it will be overwritten. Parent directories will be created at the target path if necessary. Specifying the flag SYNCHRONIZE_FLAG_NO_OVERWRITE_DIRECTORY will cause the synchronization to throw an exception if a non-empty directory already exists at the target. Empty directories at the target path will be deleted and overwritten with the byte contents of the source file.

If the source file is a directory, then a directory will be created at the target path. Children of the source directory are not synchronized. If a file already exists at the target path, it will be deleted and a directory is created instead. If a directory already exists at the target path, no operations are done. Parent directories are created appropriately.

The implementation doesn't examine the nature of the retrieved paths. If there are conflicting paths, then the resulting map may be smaller in size than the passed input. E.g. If multiple files have no parent, but same file name, only one will be in the result map with its name.

When calling this during remote execution, it is recommended that the files reside on the coordinator machine.

The implementation doesn't examine the nature of the retrieved paths. If there are conflicting paths, then the resulting map may be smaller in size than the passed input. E.g. If multiple files have no parent, but same file name, only one will be in the result map with its name.

When calling this during remote execution, it is recommended that the files reside on the coordinator machine.

Calling this method might implicitly synchronize the file to its real location, or to some other cache location when remote execution is used.

Calling this method might implicitly synchronize the file to its real location, or to some other cache location when remote execution is used.