Always include Gradle API stubs in GradleParser classpath

[pstreef]

Problem

When settingsClasspath or buildscriptClasspath is explicitly set on GradleParser.Builder (even to an empty list), the parser replaces the default Gradle API stubs entirely instead of merging them. This causes incorrect type attribution on DSL methods like pluginManagement(), repositories(), and gradlePluginPortal().

For example, pluginManagement() ends up with a garbage declaring type like org.gradle.api.initialization.org.gradle.api.initialization.13789550265458Kt instead of the correct org.gradle.api.initialization.Settings. Recipes that use MethodMatcher (e.g. FindRepository) then fail to match these methods, causing downstream recipes like AddSettingsPluginRepository to not detect existing entries and add duplicates.

This happens in practice when the Gradle plugin extracts the settings buildscript classpath (typically empty when there are no custom settings plugins) and passes it to GradleParser.

Solution

Introduce mergeClasspath() which always includes the default Gradle API stubs (gradle-core-api, gradle-base-services, etc.) alongside any externally-provided classpath, using a LinkedHashSet to avoid duplicates. All four parser initialization paths (groovy/kotlin x build/settings) now use this method.

Includes a reproducer test that sets settingsClasspath to an empty list and verifies AddSettingsPluginRepository correctly detects an existing gradlePluginPortal().

• See also Fix duplicate gradlePluginPortal() in settings.gradle.kts #7230 which adds a recipe-level workaround for the same symptom.

[shanman190]

When parsing Gradle scripts in process, the Gradle API will be available, so we wouldn't want to add the Gradle 6 implementation of classes back in that we use when out of process as a workaround.

The class value discovered looks like a dynamic proxy which likely extends the target class, so that makes me suspicious that our matcher isn't checking supertypes in FindRepository.

[sambsnyd]

Makes sense to me

[sambsnyd]

When parsing Gradle scripts in process, the Gradle API will be available, so we wouldn't want to add the Gradle 6 implementation of classes back in that we use when out of process as a workaround.

That's a good point. Of course we also use GradleParser in recipes to generate new LST snippets and we do want the API available there as much as possible.

The class value discovered looks like a dynamic proxy which likely extends the target class, so that makes me suspicious that our matcher isn't checking supertypes in FindRepository.

That sounds plausible

[shanman190]

That's a good point. Of course we also use GradleParser in recipes to generate new LST snippets and we do want the API available there as much as possible.

Yep. In recipes, we don't configure a classpath (buildscript or settings), so that is what results in use default loading the Gradle 6 shim already.

[pstreef]

Thanks for the detailed feedback. You raise a good point about the in-process case — DefaultProjectParser runs inside Gradle where the real API is on the classloader, so unconditionally merging the bundled Gradle API jars isn't right.

The supertype/dynamic proxy angle is interesting too. I'm going to leave this PR as draft — @shanman190, would you be open to picking up the root cause fix? You clearly have better context on the MethodMatcher/FindRepository interaction and the in-process parsing constraints.

In the meantime, #7230 (the recipe-level workaround) is merged and handles the immediate symptom. I have a follow-up ready for Shannon's review comment there too (#7245 — gating the name-based fallback on url == null so it doesn't incorrectly block multiple maven {} entries).