Is SetProperty<File> with @InputFiles fully supported?

Help/Discuss
1

Hi. I consider to change Set<File> to SetProperty<File> in my task to be used together with @InputFiles.

    @InputFiles
    final SetProperty<File> sourceDirs

I wonder, if all the files-related features of Gradle will be supported in that configuration?

In addition, the documentation mentions:

@InputFiles
final ListProperty<RegularFile> inputFiles

which should be more Gradle-like, however, I found it problematic to convert:

extension.mainSourceSets.get()*.allSource.srcDirs.flatten()

to SetProperty<RegularFile> (in particular creating a RegularFile instance from an arbitrary File). Can it be done in any simple way?

2

Hi Marcin,

why don’t you use ConfigurableFileCollection?

Cheers,
Stefan

3

I use FileCollections in some other places in my code (e.g. for the execution classpath), but for sourceDirs and mutableCodePaths it seemed to be easier to have just Set<File> - I just pass it to PIT as a list of paths.

How would be best to get (for example) just source directories (not whole classpath) from source sets as (Configurable)FileCollection?

4

A FileCollection is an Iterable<File>, so you should be able to do everything you do on a Set<File>.

5

@Stefan_Wolf, I gave it a try and in general it works.

However, I have some related questions.

ConfigurableFileCollection doesn’t seem to provide any find of provider() which logic could be lazy evaluated on the FileCollection materialization. As a result I’m not sure how to convert my current logic (in some places) to use modifiable ConigurableFileCollection (and something like setFrom() instead of just setting FileCollection instance in my task:

task.conventionMapping.with {
    additionalClasspath = {
        List<FileCollection> testRuntimeClasspath = extension.testSourceSets.get()*.runtimeClasspath

        FileCollection combinedTaskClasspath = new UnionFileCollection(testRuntimeClasspath)
        FileCollection filteredCombinedTaskClasspath = combinedTaskClasspath.filter { File file ->
            !extension.fileExtensionsToFilter.getOrNull().find { extension -> file.name.endsWith(".$extension") }
        }

        return filteredCombinedTaskClasspath
    }
    ...
}

or (here configuration might not be created yet):

launchClasspath = {
    project.rootProject.buildscript.configurations[PITEST_CONFIGURATION_NAME]
}

Do I need to use afterEvaluate {}?

6

You can always add a provider or a callable of a list of files or something like that in setFrom. Can you show me the concrete use-case what you want to set on fileCollection? Do you want to use a convention, which is built into the property types but not into ConfigurableFileCollection?

1 Like
7

I completely forgot about that forum topic :-/.

In the meantime, I created related one here with some real-life case: How to ConfigurableFileCollection.setFrom with Provider?

See also the source code for other cases: https://github.com/szpak/gradle-pitest-plugin/blob/8a7da3fd3efe33cc24e8ad227ec9721beb233f8f/src/main/groovy/info/solidsoft/gradle/pitest/PitestPlugin.groovy#L171-L186

8

After your latest suggestion @Stefan_Wolf I solved it with Callable as detailed here. Thanks.

9

One more related question @Stefan_Wolf :-).

In my plugin’s extension class I had:

Set<File> additionalMutableCodePaths

which I replaced with:

final SetProperty additionalMutableCodePaths

However, in the task I have:

final ConfigurableFileCollection mutableCodePaths

Is it worth to replace SetProperty<File> with ConfigurableFileCollection also in my extension class?

This property is used to provide additional mutable code paths, e.g. from some :shared module to be also mutated (processed), e.g.

//mutableCodeBase - additional configuration to resolve :shared project JAR as mutable code path for PIT
configurations { mutableCodeBase { transitive false } }
dependencies { mutableCodeBase project(':shared') }
pitest {
    mainSourceSets = [project.sourceSets.main, project(':shared').sourceSets.main]
    additionalMutableCodePaths = [configurations.mutableCodeBase.singleFile] //<-- this place
}

What would be best (what type is recommended) to implement additionalMutableCodePaths (at the extension level)?