Prefer the static FlowrDescriptionFile.from method to create instances of this class as it will not re-create if already a description file and handle role assignments.
Protected
fileOptional
Readonly
roleThe role of this file, if any, in general your file should not decide for itself what role it has in the project context, this is for the loaders plugins to decide (cf. PluginType) as they can, e.g., respect ignore files, updated mappings, etc. However, they will 1) set this role as soon as they decide on it (using assignRole) and 2) try to respect an already assigned role (however, user configurations may override this).
Static
fromDescription file lifter, this does not re-create if already a description file
Optional
role: SpecialFileRoleAssign a role to this file, this should be done by the loader plugins (cf. PluginType). Do not call this method yourself unless you are a file-loader plugin and/or really know what you are doing, this may break plugin assumptions!
The content of the file, this may be cached by the implementation and does not have to be expensive. You can used stream based implementations but right now there is no external, project-wide expressions of life cycles for files. So make sure your implementation closes the resource as soon as possible.
Protected
loadThe path to the file, this is used for identification and logging purposes. If the file does not exist on disk, this can be a virtual path (e.g. for inline files). Even though this is a getter, please make sure that the operation is cheap and deterministic (some decorators may overwrite the path, e.g., because they support other protocols).
This decorates a text file and provides access to its content as a DCF (Debian Control File)-like structure.