Possible root cause for SourceSet with name 'crossBuildScala_211' not found

[bmuschko]

I am running into the following issue below for a project dependency that is not a Scala project and doesn't apply the plugin either. Do you have any idea what the root cause could be based on the stack trace? The error message bubbles up all the way to the Gradle core API. Unfortunately, I cannot reproduce the issue in the sample project of mine.

SourceSet with name 'crossBuildScala_211' not found.

* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Exception is:
org.gradle.api.UnknownDomainObjectException: SourceSet with name 'crossBuildScala_211' not found.
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.createNotFoundException(DefaultNamedDomainObjectCollection.java:504)
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.getByName(DefaultNamedDomainObjectCollection.java:333)
	at org.gradle.api.NamedDomainObjectCollection$getByName$1.call(Unknown Source)
	at com.github.prokod.gradle.crossbuild.utils.SourceSetInsightsView.switchTo(SourceSetInsightsView.groovy:37)
	at com.github.prokod.gradle.crossbuild.utils.SourceSetInsightsView$switchTo$0.call(Unknown Source)
	at com.github.prokod.gradle.crossbuild.utils.DependencyInsights$_generateDetachedDefaultConfigurationsRecursivelyFor_closure12.doCall(DependencyInsights.groovy:231)
	at com.github.prokod.gradle.crossbuild.utils.DependencyInsights.generateDetachedDefaultConfigurationsRecursivelyFor(DependencyInsights.groovy:229)
	at com.github.prokod.gradle.crossbuild.utils.DependencyInsights.generateDetachedDefaultConfigurationsRecursivelyFor(DependencyInsights.groovy:200)
	at com.github.prokod.gradle.crossbuild.utils.DependencyInsights.generateDetachedDefaultConfigurationsRecursively(DependencyInsights.groovy:173)
	at com.github.prokod.gradle.crossbuild.utils.DependencyInsights.addDefaultConfigurationsToCrossBuildConfigurationRecursive(DependencyInsights.groovy:101)
	at com.github.prokod.gradle.crossbuild.utils.DependencyInsights$addDefaultConfigurationsToCrossBuildConfigurationRecursive$0.call(Unknown Source)
	at com.github.prokod.gradle.crossbuild.CrossBuildPlugin$_generateNonDefaultProjectTypeDependencies_closure13.doCall(CrossBuildPlugin.groovy:292)
	at com.github.prokod.gradle.crossbuild.CrossBuildPlugin.generateNonDefaultProjectTypeDependencies(CrossBuildPlugin.groovy:279)
	at com.github.prokod.gradle.crossbuild.CrossBuildPlugin$_apply_closure4.doCall(CrossBuildPlugin.groovy:72)

[prokod]

Hi @bmuschko can you share some more details ? gradle files maybe ? unfortunately the stack trace is not enough.
Also I link the test that covers this scenario where one module is non scala one (hence not cross build). I hope this helps.

gradle-crossbuild-scala/src/test/groovy/com/github/prokod/gradle/crossbuild/CrossBuildPluginCompileMultiModuleAdvancedTest.groovy

Line 2400 in 7894e03

def "[gradle:#gradleVersion | default-scala-version:#defaultScalaVersion] applying crossbuild plugin on a multi-module project with dependency graph of depth 3 and with no _? scala tag results in correct resolved scala deps"() {

[bmuschko]

Unfortunately, I cannot share details as the issue occurs in a large multi-project build. I don't think it would even help as I cannot really localize what cause the issue and can't reproduce it in isolation. I know what project dependency causes the issue but don't know why. Can you explain what you code tries to do at com.github.prokod.gradle.crossbuild.utils.SourceSetInsightsView.switchTo(SourceSetInsightsView.groovy:37)? I didn't have a deep look but it seems to look at project dependencies and then locate a specific source set. Maybe we could change the code to be more defensive e.g. see if the source set with the name exists, if it doesn't then don't try to resolve it but fail with a useful error message?

For now, I can work around by using the default configuration for the project dependency, as shown below.

dependencies {
    implementation project(path: ':mypath', configuration: 'default')
}

[prokod]

I see. Well can you at least put the multi project modules layout as a tree representation and point out which one is failing?
I will try in the meantime using the stack trace to work something out

[prokod]

Can you explain what you code tries to do at com.github.prokod.gradle.crossbuild.utils.SourceSetInsightsView.switchTo(SourceSetInsightsView.groovy:37)? I didn't have a deep look but it seems to look at project dependencies and then locate a specific source set. Maybe we could change the code to be more defensive e.g. see if the source set with the name exists, if it doesn't then don't try to resolve it but fail with a useful error message?

This is not an important method the actually interesting part is here: at com.github.prokod.gradle.crossbuild.utils.DependencyInsights$_generateDetachedDefaultConfigurationsRecursivelyFor_closure12.doCall(DependencyInsights.groovy:231)
The documentation for the method:

/**
     * Valid (= projects that cross build gradle plugin was applies to) Projects 'default' dependency set
     * is being searched for other project type dependencies by searching the dependency tree.
     * All the 'default' configurations for the found {@link ProjectDependency#getDependencyProject} are being
     * accumulated recursively and returned.
     *
     * NOTEs:
     * 1. Only those {@link ProjectDependency} with targetConfiguration as 'default' are being considered.
     * 2. This method is bound by the visibility to the modules that the cross build plugin is applied to.
     *    See modules parameter.
     *    In a lazy applied plugin type of build.gradle, the full set of modules is visible in
     *    {@code projectsEvaluated{}} and later.
     *
     * @param dependencyProject The project for which we collect it's processed 'default' configuration
     * @param modules Set of modules cross build plugin was applied to.
     *                see {@link #extractCrossBuildProjectTypeDependencies}
     * @return a set of detached configurations derived from the 'default' configuration found in the dependency tree
     */

It seems to me the way you apply the plugin and the complex (probably) scenario revealed a bug. It would be nice to try and work with you towards understanding and fixing :)

Cheers

[bmuschko]

OK, here are some details. Not sure if it will help but we'll see.

1. The multi-project build consists of 150-200 subprojects. The project contains a mix of Scala, Java, and Android subprojects.
2. There's a root build.gradle file. Most subprojects have their own build.gradle file with configuration specific to the subproject.
3. You plugin is applied using the plugins DSL in the root build.gradle file. The apply flag is set to false.
4. Each Scala subproject applies your plugin with the help of a precompiled script plugin under buildSrc and configures additional Scala settings like compiler options. This script plugin is applied in a loop in the root build.gradle file.
5. The issue shows up for a specific subproject (non-Scala) that is assigned as project dependency to a Scala project. The assignment happens via implementation project(':problematic').
6. At this time, there isn't a lot of usage of afterEvaluate. At least not in the portions of code that I mentioned above.