This message was deleted.

The

SourceSetContainer

is available as the

sourceSets

extension on the project, that should be available right away (type-safe accessor) in a precompiled script plugin (assuming you applied the

jvm-cosystem-plugin

in your

plugins{}

block). In other words, "just" use

sourceSets.create(…)

. https://github.com/gradle/gradle/blob/1501cc643d9723e053739128ac718145210e3185/pla[…]vm/src/main/java/org/gradle/api/plugins/JvmEcosystemPlugin.java https://github.com/gradle/gradle/blob/1501cc643d9723e053739128ac718145210e3185/pla[…]a-base/src/main/java/org/gradle/api/plugins/JavaBasePlugin.java

I don't want to apply a jvm plugin but create a new language plugin. My current workaround is a creating a "normal" plugin called in my precompiled script plugin:

class CreateSourceSetContainerPlugin @Inject constructor(private val sourceSets: SourceSetContainer) : Plugin<Project> {
    override fun apply(target: Project): Unit = with(target) {
        if (extensions.findByType<SourceSetContainer>() == null) {
            extensions.add("sourceSets", sourceSets)
        }
    }
}

But ideally, there should be a way to support service injection with precompiled scripts.

There is a way, but let me also ask again, just to make sure. You want to create a source set. Source sets are a concept of the JVM ecosystem. Hence the

jvm-ecosystem

plugin adds the source set container. Actually the only things that plugin does, is creating the source set container, configuring the strategy how variants are derived from non GMM metadata, and configuring the attribute schema accordingly. If you want to create a new language plugin that lives in the JVM ecosystem, why not simply applying the

jvm-ecosystem

plugin?

My use-case is my cobol gradle plugin, which mostly will be used in combination with the Java/Kotlin JVM plugin, but should also work without any JVM plugin when not targeting the JVM but plain cobol. But I will take a look at the jvm-ecosystem plugin and its (side) effects.