Undeclared build service deprecation when enabling stable configuration cache

[ciscoo]

If you are submitting a bug, please include the following:

• summary of problem
• gradle or maven version
• spotless version
• operating system and version
• copy-paste your full Spotless configuration block(s), and a link to a public git repo that reproduces the problem if possible
• copy-paste the full content of any console errors emitted by gradlew spotless[Apply/Check] --stacktrace

If you're just submitting a feature request or question, no need for the above.

---

Gradle 7.5 adds a new feature preview flag for stable configuration cache. When enabled, warnings appear due to Spotless' undeclared usage of SpotlessTaskService:

https://docs.gradle.org/7.5/release-notes.html#new-stable_configuration_cache-feature-flag

> Task :spotlessKotlinGradleApply UP-TO-DATE
Build service 'SpotlessTaskService' is being used by task ':spotlessKotlinGradleApply' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#undeclared_build_service_usage

> Task :cxf-codegen-gradle:spotlessJava
Build service 'SpotlessTaskService' is being used by task ':cxf-codegen-gradle:spotlessJava' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#undeclared_build_service_usage

> Task :cxf-codegen-gradle:spotlessJavaApply
Build service 'SpotlessTaskService' is being used by task ':cxf-codegen-gradle:spotlessJavaApply' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#undeclared_build_service_usage

> Task :cxf-codegen-gradle:spotlessKotlinGradleApply UP-TO-DATE
Build service 'SpotlessTaskService' is being used by task ':cxf-codegen-gradle:spotlessKotlinGradleApply' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#undeclared_build_service_usage

> Task :documentation:spotlessJavaApply UP-TO-DATE
Build service 'SpotlessTaskService' is being used by task ':documentation:spotlessJavaApply' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#undeclared_build_service_usage

> Task :documentation:spotlessKotlinGradleApply UP-TO-DATE
Build service 'SpotlessTaskService' is being used by task ':documentation:spotlessKotlinGradleApply' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5/userguide/upgrading_version_7.html#undeclared_build_service_usage

• Gradle 7.5
• Java 11 Temurin
• Spotless 6.8.0
• Linux Mint 20.3

You can see the warnings with a plugin I maintain. Specific Spotless configuration here: https://github.com/ciscoo/cxf-codegen-gradle/blob/master/buildSrc/src/main/kotlin/code-style-conventions.gradle.kts

[nedtwigg]

Fixed in plugin-gradle 6.9.0.

[nedtwigg]

I have complained a fair bit about the design of the configuration-cache

• Petition Gradle to support JVM-local configuration-cache #987

And I've also had to ask a lot of questions about how to correctly use BuildService, and there is a lot of ceremony involved.

• Configuration cache, part 1 (play nice with others) #720

For one thing, you can't just register "this class is my one-per-build BuildService", and then ask for that using the class as the key anywhere in Gradle. You instead have to imperatively register the service, and pass the handle to that registered service around.

spotless/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/RegisterDependenciesTask.java

Lines 65 to 66 in 3878d36

	BuildServiceRegistry buildServices = getProject().getGradle().getSharedServices();
	taskService = buildServices.registerIfAbsent("SpotlessTaskService" + compositeBuildSuffix, SpotlessTaskService.class, spec -> {});

And, you can't pass it as just a regular field. Any task that uses it must declare a magically-generated "property getter", as such:

@Internal
public abstract Property<GitRatchetGradle> getGitRatchet();

The service then has to explicitly passed from Property to Property, which adds more boilerplate given that could be a global singleton injected based purely on GitRatchetGradle.class as the key.

spotless/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/SpotlessTaskImpl.java

Line 51 in 3878d36

getTaskService().set(service);

Now, it turns out that is not enough boilerplate, you also have to call Task#usesService(Provider<BuildService>). Fine, so we'll add that. But if you've been passing the service between these magical Property<Blash> getProperty() gizmos, (btw Property extends Provider), you're about to hit another problem!

https://github.com/gradle/gradle/blob/262dcd02073f2b93ba1f88a863d0613d5f081d06/subprojects/core/src/main/java/org/gradle/api/services/internal/DefaultBuildServicesRegistry.java#L102-L105

A Provider<BuildService> is not good enough, it has to be a org.gradle.api.services.<INTERNAL!!!>.BuildServiceProvider, and only the very first call to register is one of those. As you pass that instance around to other tasks, those are just regular Provider, so you cannot use them for Task.usesService.

SOoooooo, we had to add even more boilerplate

• 3d12cb0

• spotless/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/SpotlessTaskImpl.java

  Lines 55 to 61 in 3878d36

  	// this field is stupid, but we need it, see https://github.com/diffplug/spotless/issues/1260
  	private transient Provider<SpotlessTaskService> taskServiceProvider;
  	@Internal
  	Provider<SpotlessTaskService> getTaskServiceProvider() {
  	return taskServiceProvider;
  	}

so that we have the magical property getter to play nicely with configuration cache deserialization AND the internal.BuildServiceProvider to play nicely with Task.usesService.

I continue to love Gradle, and I continue to be super-duper flummoxed by the design of BuildServices and of ConfigurationCache. For each of these pieces, it would be good to be really clear about "what are the invariants", and "what is the key". IMO, for BuildService, the answers should be "the key is the class" and the invariant is "there is exactly one instance of this class throughout this build, and it will be created fresh on each build, and maybe we promise to never call this class from multiple threads (I don't care)". For "configuration cache", the invariant is "a task is being run and the exact same task was run earlier on this same JVM" and the key is "the task and the JVM". IMO. I'll do my best to make Spotless work worry-free with Gradle as it is designed.