I believe your analysis is correct. There doesn’t appear to be a way to get an instance of a FileCollection while evaluating the settings.gradle file. Out of curiosity, what are you trying to do that makes you want to use the FileCollection API in your settings.gradle file? Maybe there is a missing feature we can identify and deal with in a straight-forward manner?
@Lance, sorry for the delay in reply. At this point, I think we’re talking about an actual feature request for Gradle (as opposed to general discussion and help requests.) Would you mind formalizing this request by opening an issue on the https://github.com/gradle/gradle repository?
And, missing any documentation about a Settings.files() analogous to the Project.files(), I assumed that it wouldn’t work. In fact, you cannot call Settings.files() but have to just use files() directly. I haven’t yet figured out where this function comes from, but I’ll see if I can figure it out. Then, I’ll open a documentation bug.
I found it.
So, all gradle build scripts end up being applied using a ScriptTarget inside DefaultScriptPluginFactory:
The ScriptTarget for the settings.gradle file wraps a SettingsInternal typed target, so you can see from the logic above, it’s going to create either a InitialPassSettingsScriptTarget or a SettingsScriptTarget depending on which execution pass Gradle is on. InitialPassSettingsScriptTarget extends from SettingsScriptTarget:
Which tells the DefaultScriptPluginFactory to construct a SettingsScript class to represent the target by returning that class from its getScriptClass() method:
when the DefaultScriptPluginFactory asks for it here:
The scriptType is used to create ScriptRunner instances based on the scriptType on lines 177 and 192 above.
The ScriptRunner instances end up instantiating instances of the scriptType to run the scripts. Because the SettingScript class extends from DefaultScript …:
… which extends from BasicScript …:
… which implements FileOperations:
… and, because FileOperations defines the files() and file() methods (among others) …:
… you can conclude that you are allowed to use file() and files() directly in your settings.gradle file.
Now, arguably, you are not allowed to use them because the whole FileOperations interface is in an internal package which means Gradle reserves the right to change these implementation details without a deprecation period.
And, it would probably be hard for a user of Gradle to discover how all of this is tied together without walking through the code I just tried to explain above. But, at least we know one way you could find it out.
They come from SettingsScript extends DefaultScript. These are not part of the public API actually, just some magic we weave into Groovy scripts for convenience.
I think it makes sense to add a statically typed API, but we shouldn’t add all those overloaded methods to Settings. In fact we want to get rid of them on Project in the long run. Instead we could provide something like Settings.getFileOperations() (for lack of a better name).