Gradle ProtobufPluginAction breaks configuration cache

[tommyk-gears]

After the changes in 4.1.1 the generateProto task is no longer compatible with gradle configuration cache.

I get this error message when i try to use generateProto with configuration cache enabled (on 4.1.0 it works with configuration cache);

• Task :examples:example-service:generateProto of type com.google.protobuf.gradle.GenerateProtoTask: cannot serialize object of type 'org.gradle.api.internal.file.DefaultSourceDirectorySet', a subtype of 'org.gradle.api.file.SourceDirectorySet', as these are not supported with the configuration cache.
  See https://docs.gradle.org/9.7.1/userguide/configuration_cache_requirements.html#config_cache:requirements:disallowed_types

The cause seems to be that protobuf.generateProtoTasks(this::configureGenerateProtoTasks); is called inside the lambda sent to configureEach here. I think it can be fixed by just moving that call outside the lambda (and guard it by its own if (plugins.findByName("grpc") != null)).

[wilkinsona]

Thanks for the analysis.

I'm quite reluctant to make that sort of code change. It adds (a small amount of) complexity to our codebase, resulting in code that looks out of place and is likely to be re-written in the future, re-introducing the problem.

It's this kind of limitation that means that, from my perspective as a plugin maintainer, Gradle's configuration cache isn't ready for primetime. The maintenance burden of supporting it is too high as there are still too many sharp edges.

I'll raise it with the Gradle team and see where we go from here.

[wilkinsona]

I think it can be fixed by just moving that call outside the lambda (and guard it by its own if (plugins.findByName("grpc") != null))

While we wait to hear from the Gradle team, I've been exploring options and I don't think this one will work.

The code as currently implemented is lazy (as Gradle plugins should be) and whenever the grpc plugin is added, Boot customises the generate proto tasks. Assuming I've understood the suggestion correctly, moving the call outside the lambda will lose the laziness such that if the grpc plugin hasn't been applied by the timefindByName is called, the customization of the generate proto tasks will be missed.