Add missing buildscript classpath configuration

[shanman190]

What's changed?

Now capturing the buildscript classpath dependency configuration.

What's your motivation?

I was reminded that this configuration was presently not being captured during the review of #4376, so this means that the GradleDependency trait fails to match buildscript dependencies.

Anything in particular you'd like reviewers to focus on?

I've moved plugin repositories into the GradleBuildscript nested object. The thought is that this more closely aligns the purposes of the repositories from a code discoverability standpoint and the expectation is for the new style to be non-null. Given current serialized LSTs, there's an internal null check to help make sure to avoid some of the possible NullPointerException cases.

Anyone you would like to review specifically?

@sambsnyd

Have you considered any alternatives or workarounds?

• Could potentially add the classpath configuration to the existing nameToConfiguration map, but presently this is tracking project configurations. So by doing so we'd be blending the buildscript and project configuration together which is probably not desirable.
• Could potentially add a GradleDependencyConfiguration directly on the marker objects themselves to capture the same information, but again we're now capturing more information about the buildscript itself and having to use the naming conventions to differentiate between the buildscript settings and the project settings.

Any additional context

I would have liked to go ahead and drop the mavenPluginRepositories altogether, but I suspected that previously serialized LSTs could cause us some grief.

openrewrite/rewrite-gradle-tooling-model#23

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[sihutch]

@sambsnyd @shanman190 I am getting failing tests on main since this merge. All have the same cause

Caused by: java.lang.NoClassDefFoundError: org/openrewrite/gradle/marker/GradleBuildscript at org.openrewrite.gradle.marker.GradleProjectBuilder.gradleProject(GradleProjectBuilder.java:76) at org.openrewrite.gradle.toolingapi.ToolingApiOpenRewriteModelPlugin$OpenRewriteModelBuilder.buildAll(ToolingApiOpenRewriteModelPlugin.java:53) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$BuilderWithNoParameter.build(DefaultToolingModelBuilderRegistry.java:264) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$UserCodeAssigningBuilder.lambda$build$0(DefaultToolingModelBuilderRegistry.java:374) at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication.reapply(DefaultUserCodeApplicationContext.java:109) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$UserCodeAssigningBuilder.build(DefaultToolingModelBuilderRegistry.java:374) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$LockSingleProjectBuilder.lambda$build$0(DefaultToolingModelBuilderRegistry.java:304) at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.lambda$fromMutableState$2(DefaultProjectStateRegistry.java:429) at org.gradle.internal.work.DefaultWorkerLeaseService.withReplacedLocks(DefaultWorkerLeaseService.java:360) at org.gradle.api.internal.project.DefaultProjectStateRegistry$ProjectStateImpl.fromMutableState(DefaultProjectStateRegistry.java:429) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$LockSingleProjectBuilder.build(DefaultToolingModelBuilderRegistry.java:304) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$BuildOperationWrappingBuilder$1.call(DefaultToolingModelBuilderRegistry.java:337) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204) at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199) 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.call(DefaultBuildOperationRunner.java:53) at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:78) at org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$BuildOperationWrappingBuilder.build(DefaultToolingModelBuilderRegistry.java:334) at org.gradle.internal.build.DefaultBuildToolingModelController$AbstractToolingScope.getModel(DefaultBuildToolingModelController.java:82) at org.gradle.tooling.internal.provider.runner.BuildModelActionRunner$ModelCreateAction.fromBuildModel(BuildModelActionRunner.java:83) at org.gradle.internal.buildtree.DefaultBuildTreeModelCreator.fromBuildModel(DefaultBuildTreeModelCreator.java:57) at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.lambda$fromBuildModel$2(DefaultBuildTreeLifecycleController.java:81) at org.gradle.internal.buildtree.DefaultBuildTreeLifecycleController.lambda$runBuild$4(DefaultBuildTreeLifecycleController.java:98

[shanman190]

@sihutch, do you by chance have some old rewrite snapshots published to the mavenLocal() repository? The latest published snapshots or creating a new local snapshot should fix that.