buildSrc dependencies leaks are not visible in gradlew buildEnvironment

[Tolriq]

Expected Behavior

I have read #4741 and understood that it's normal that the buildSrc dependencies currently leak even if using implementation.

But due to the lack of resolution this can cause build issues because any dependency declared in buildSrc will override later declarations.
While this is an issue the main issue is that gradlew buildEnvironment does not report the dependencies from buildSrc but the normal declarations. Making very very hard to debug dependencies issues when there's no direct build issues.

Current Behavior

gradlew buildEnvironment does not return the real dependencies that are used!

Context

My project is build with wrong dependencies used and since there was no errors I had no way to know that I was using the wrong ones.

Steps to Reproduce (for bugs)

Gradle 5.1.1 / Windows

In buildSrc/build.gradle.kts

dependencies {
    implementation("com.android.tools.build:gradle:3.3.0")
}

in the application root build.gradle.kts

buildscript {
    dependencies {
        classpath("com.android.tools.build:gradle:3.4.0-beta1")
     }
}

Running gradlew buildEnvironment will produce

classpath
+--- com.android.tools.build:gradle:3.4.0-beta01

But in reality version 3.3.0 will be used. If the plugin does not log it's version it's virtually impossible to know that wrong dependency is used.

[bigdaz]

Unfortunately, the buildEnvironment task only reports on the resolved classpath of the project itself: the buildSrc dependencies leak in via classloader hierarchy, not via dependency resolution.

So the best idea I have to fix the reporting would be for buildEnvironment to include an additional report of buildSrc.compileClasspath. (You can see this by running gradle dependencies from inside the buildSrc directory).

Unfortunately the Gradle team have limited capacity to work on improvements, and prioritization is hard. @Tolriq would you be interested in helping out with a fix?

[rkrisztian]

In a big Gradle project this can be really confusing and time consuming to debug. Guava versions below 21 have been causing issues for so long, and so many libraries depend on such versions. It is not straightforward at all to look into buildSrc too. Please give this ticket more priority.

[TWiStErRob]

@Tolriq long time no see 👋.

@Tolriq @rkrisztian @autonomousapps @martinbonnin @deeTEEcee What's the reason for having a mix of buildSrc and classpath dependencies? For us, it's simply a long migration to buildSrc in progress.

@bigdaz Do you think that moving all the dependencies to be declared in buildSrc is a viable workaround? In that case buildEnvironment would still give a bad output, but buildSrc > dependencies will always give a full picture because there would be no buildscript.dependencies.classpaths mixing things up.

[autonomousapps]

Lots of plugins don't publish proper descriptors, and so you have to use the classpath approach. I don't think I should be forced to declare all dependencies in buildSrc?

[martinbonnin]

For what it's worth, when I'm in need of a buildSrc directory, I usually move all the plugins to the dependencies {} block there to avoid having conflicting dependencies. I do this using the old implementation("$group:$artifact:$version") syntax, but I can still use the plugins {} block in the rootProject modules since the plugins are then in the classpath.

I know the Gradle team is moving to convention-plugins and using them from regular included builds (and not buildSrc). I haven't wrapped my head 100% around this but there's a good exemple there: https://github.com/jjohannes/idiomatic-gradle

[eskatos]

Related issues

• Buildscript classpath of submodules is wrongly resolved #12572
• How exactly does classpath of buildSrc interact with classpath of buildscript? #25944

[mlopatkin]

The issue is in the backlog of the relevant team and is prioritized by them.

---

We may probably fix this before doing any changes to the classloader structure, but this is unlikely to happen in the short or medium term.