Premature file validation in ToolsLocator causes slowdown during configuration phase

[steffenyount]

I'm trying to use the protobuf-gradle-plugin in an environment with hundreds of gradle projects. In this environment it is vital that we keep the Configuration phase time spent on each of the individual projects down to a minimum since they accumulate to affect every subsequent invocation of gradle. For the most part we have achieved acceptable Configuration phase times by making sure that all our projects' dependency resolution and related file I/O is deferred to the Execution phase.

One simple test we use for detecting premature dependency resolution and related file I/O has been to run 'gradlew help --profile' from the root project directory, and then to look at the results under the 'Dependency Resolution' tab. The only entries we should find there when running the 'gradlew help' target are the unavoidable project classpath entries ending in '**:classpath'. Any other entries found there indicate premature dependency resolution and related file I/O being done during the Configuration phase for the listed dependency.

The protobuf-gradle-plugin is failing this test. We're seeing numerous entries ending in '**:protobufToolsLocator_protoc' under the 'Dependency Resolution' tab, and these are cumulatively adding more than a second to our total Configuration phase time on every invocation of gradle.

Looking at the source code it seems that the cause of this slowdown are lines 88-91 of ToolsLocator.groovy:

    File file = config.fileCollection(dep).singleFile
    if (!file.canExecute() && !file.setExecutable(true)) {
      throw new GradleException("Cannot set ${file} as executable")
    }

Where the config.fileCollection(dep).singleFile is forcing dependency resolution to happen during the Configuration phase and then the !file.canExecute() && !file.setExecutable(true) is also forcing file I/O to happen during the Configuration phase.

Can this be refactored to either 1) remove this dependency check here, 2) allow this dependency check to be disabled here, or even better yet 3) defer this dependency check until the Execution phase when the item being verified is actually going to be used?