6.6.1 eagerly resolves configurations

[ZacSweers]

When trying to upgrade from 6.6.0 to 6.6.1 in Gradle 7.4.2 on macOS Monterey, we see a strange exception start coming from AGP when it tries to modify a kapt configuration that has already been resolved. The only change here is the spotless upgrade however, so I'm not sure what else it could be than spotless resolving it early.

Our spotless config is here: https://github.com/slackhq/slack-gradle-plugin/blob/1cf68e8504c562c9b67d4e53821dd0b81b4031d2/slack-plugin/src/main/kotlin/slack/gradle/StandardProjectConfigurations.kt#L232

Caused by: java.lang.IllegalArgumentException: Cannot change attributes of dependency configuration ':apps:app-di:kapt' after it has been resolved
        at org.gradle.api.internal.attributes.ImmutableAttributeContainerWithErrorMessage.attribute(ImmutableAttributeContainerWithErrorMessage.java:58)
        at com.android.build.gradle.internal.DependencyConfigurator$configureGeneralTransforms$12.execute(DependencyConfigurator.kt:424)
        at com.android.build.gradle.internal.DependencyConfigurator$configureGeneralTransforms$12.execute(DependencyConfigurator.kt:420)
        at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
        at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction$1.run(DefaultCollectionCallbackActionDecorator.java:110)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
        at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
        at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:47)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:68)
        at org.gradle.api.internal.DefaultCollectionCallbackActionDecorator$BuildOperationEmittingAction.execute(DefaultCollectionCallbackActionDecorator.java:107)
        at org.gradle.api.internal.DefaultDomainObjectCollection.all(DefaultDomainObjectCollection.java:161)
        at com.android.build.gradle.internal.DependencyConfigurator.configureGeneralTransforms(DependencyConfigurator.kt:420)
        at com.android.build.gradle.internal.plugins.BasePlugin.createAndroidTasks(BasePlugin.java:833)
        at com.android.builder.profile.ThreadRecorder.record(ThreadRecorder.java:69)
        ... 180 more

[nedtwigg]

There is in fact a change in 6.6.1 that causes each FormatterStep to resolve its dependencies earlier than before (it happens in task.setSteps() which gets called inside formatExtension.setupTask).

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

Lines 63 to 72 in 63b9762

	project.afterEvaluate(unused -> {
	spotlessTask.configure(task -> {
	// now that the task is being configured, we execute our actions
	for (Action<FormatExtension> lazyAction : formatExtension.lazyActions) {
	lazyAction.execute(formatExtension);
	}
	// and now we'll setup the task
	formatExtension.setupTask(task);
	});
	});

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

Line 762 in 63b9762

task.setSteps(steps);

Previously, these were only resolved when Gradle did the up-to-date checking. The reason they were moved up is that for a failed build, some tasks might never get resolved, which led to a memory leak because the unresolved steps in the daemon cache were holding onto a reference to the Gradle project which was needed to lazily resolve dependencies.

I don't understand why this would have any effect on the kapt configuration. Maybe adding a spotlessPredeclare block can workaround the issue?

[ZacSweers]

Looks like that works for us, thanks!

[ZacSweers]

This may not actually be resolved yet, realized we weren't applying it at all in our root project. Won't be able to test it properly until #1226 is resolved

[ZacSweers]

Ok looks resolved for us with that after some updates