/**
 * Align with build-logic/cleanup/src/main/java/gradlebuild/cleanup/services/KillLeakingJavaProcesses.java
 */
enum class KillProcessMode {
    KILL_LEAKED_PROCESSES_FROM_PREVIOUS_BUILDS,
    KILL_PROCESSES_STARTED_BY_GRADLE,
    KILL_ALL_GRADLE_PROCESSES
}

internal
fun Project.addSourceSet(testType: TestType): SourceSet {
    val prefix = testType.prefix
    val sourceSets = the<SourceSetContainer>()
    val main by sourceSets.getting
    return sourceSets.create("${prefix}Test") {
        compileClasspath += main.output
        runtimeClasspath += main.output
    }
}


internal
fun Project.createTasks(sourceSet: SourceSet, testType: TestType) {
    val prefix = testType.prefix

// Using star import to workaround https://youtrack.jetbrains.com/issue/KTIJ-24390
import org.gradle.kotlin.dsl.*
import org.gradle.kotlin.dsl.support.serviceOf

/**
 * In build-logic and main build, register a BuildService instance separately,
 * which collects necessary information for build scan.
 */
fun <T : AbstractBuildScanInfoCollectingService> Project.registerBuildScanInfoCollectingService(

        // Enable it only for the main source set by default, as incremental Groovy
        // joint-compilation doesn't work with the Error Prone annotation processor
        extension.enabled.convention(this.name == "main")

        project.dependencies.addProvider(
            annotationProcessorConfigurationName,

        findLatest("slf4j", "org.slf4j:slf4j-api:(1.7,)", versionProperties)

        // Starting with ScalaTest 3.1.0, the third party integration were moved out of the main JAR
        findLatest("scalatest", "org.scalatest:scalatest_${versionProperties["scala"]}:(3.0,)", versionProperties)

 * Usage: `mvn compile exec:java@update-test-buckets -DinputTestClassDataJson=/path/to/test-class-data.json`.
 * You can get the JSON file as an artifacts of the "autoUpdateTestSplitJsonOnGradleMaster" pipeline in TeamCity.
 */
fun main() {
    val model = CIBuildModel(
        projectId = "Check",
        branch = VersionedSettingsBranch("master"),
        buildScanTags = listOf("Check"),

                exampleClass = if (descriptor.componentType === ComponentType.LIBRARY) "Hello" else "Greeter"
                sourceFile = (if (descriptor.componentType === ComponentType.LIBRARY) "Hello" else "main") + ".swift"
                testSourceFile = exampleClass + "Tests.swift"
                sourceFileTree = "        │       └── $sourceFile"
                testSourceFileTree = """                └── $testSourceFile

    unixScriptTemplate.from(layout.projectDirectory.file("../../../platforms/jvm/plugins-application/src/main/resources/org/gradle/api/internal/plugins/unixStartScript.txt"))
    windowsScriptTemplate.from(layout.projectDirectory.file("../../../platforms/jvm/plugins-application/src/main/resources/org/gradle/api/internal/plugins/windowsStartScript.txt"))
}

configurations {
    create("gradleScriptsElements") {

This has also forced plugins written in languages other than Groovy to use Groovy types for some APIs.

When the Kotlin DSL was introduced, we made an effort to add non-Groovy equivalents for all APIs.
This has been mostly done, but there remain a few holdouts (fixing these is out of scope).

To keep the Groovy DSL ergonomic, we generate methods as necessary from the non-Groovy equivalents.

Doing this provides the following specific benefits:

            attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named("gradle-source-folders"))
        }
        val main = sourceSets.main.get()
        main.java.srcDirs.forEach {
            outgoing.artifact(it)
        }
        main.groovy.srcDirs.forEach {
            outgoing.artifact(it)
        }
        main.resources.srcDirs.forEach {
            outgoing.artifact(it)
        }