Reconsider applying constraints directly to subprojects

[pkoenig10]

After spending time enabling the gradle-baseline checkImplicitDependencies task on a large internal repo, I ran into a number of papercuts due to the fragile implementation of the baseline exact dependencies tasks (for example, palantir/gradle-baseline#1593).

Relying on an after-the-fact class file analyzer to detect implicit dependencies feels like an imprecise and clunky solution.

A more elegant solution would be to simply disable transitive dependencies on the compileClasspath:

configurations {
    compileClasspath {
        transitive = false
    }    
}

This prevents compilation from succeeding if you are using implicit dependencies without introducing potential runtime failures (because the runtimeClasspath still resolves transitive dependencies).

The solution works perfectly with GCV 1.25.0, but fails with 1.26.0 due to #557.

Prior to #557, the constraints were applied directly to the rootConfiguration in each project, and each production configuration extended from the rootConfiguration. So even with transtive = false, the constraints were applied.

But after #557, the constraints are applied to a single gcvVersionsPropsConstraints configuration in the root project, and then the rootConfiguration in subprojects depends on that. As a result, the constraints are no longer applied when transitive = false.

---

I'm not sure what the motivation was behind #557, but this same behavior change is causing similar issues in interactions with other plugins (see #611). My attempts to understand the GCV logic have not been particularly successful, so it is very possible that there is some important context I am missing.

My primary intention with open this issue is to create a space to have a discussion.

[pkoenig10]

Related Gradle issue: gradle/gradle#10195

The suggestion in gradle/gradle#10195 (comment) isn't appropriate here because by configuring the dependencies themselves with transitive = false, we lose the transitivity for all other configurations in which those dependencies are used (most notably runtimeClasspath) which is undesirable.

[pkoenig10]

@fawind @CRogers curious if you have thoughts here

[carterkozak]

I believe #557 had significant impact on build times within a very large internal project, reducing time to build by several minutes and build scan size by hundreds of megabytes. I wouldn't want to revert that change unless we could do it in such a way that does not substantially regress performance.