This message was deleted.

reading in a configuration file could be done via a ValueSource

That's all already supported I think. For exec/copy inject services (ExecOperations/FileSystemOperations) in your task implementation and call exec/copy on that (same syntax as calling it on project):

@Inject
abstract protected ExecOperations getExec();
@Inject
abstract protected FileSystemOperations getFiles();

@TaskAction
public doWork() {
   getExec().exec(...)
   getFiles().copy(...)
}

For reading additional files, easiest way IMO is to do this:

providers.fileContents(...) // content will be tracked as CC input

@Jendrik Johannes I believe @Ben Berman’s suggestion is that Config Cache should detect usages of

Project.exec {}

and automatically replace them with

ExecOperations.exec {}

, so manually injecting and replacing wouldn’t be necessary. I also think it would help with complying with Config Cache restrictions.

Okay. I think that won't happen, because then you still need the

Project

object around. The problem is not the "exec" method on the object, but that the object itself would need to be kept around. That's why all the utility methods (which do not care about the actual state of the object) are replaced by services. I imagine you could do some magic code rewriting or something. But I think that would make Gradle even more confusing. Then there are some methods on Project that are not actually methods on Project.... I would rather see all of that deprecated/removed.

Anything to help with writing config cache compliant code would be appreciated! I understand it’s technically difficult, and I hope that Gradle hides that as much as possible from me. At the moment I often feel immense frustrated and confused, whether I’m writing a script or developing a plugin. It’s like I need a 6th sense to try to figure out what is compliant and what isn’t, and the config cache reports aren’t very clear, so it’s a very exhausting experience.

hopefully, now that CC is stable, we’ll see some API simplification around lazy initialization and configuration cache.

Jendrik, what if Gradle replaces Project object with a shim that internally has FileOperations. ExecOperations, and similar services? It could just fail if user calls an unsupported method