Builtin plugins can be applied via a type-safe, tooling-friendly mechanism

[bamboo]

Improve the usability of builtin plugins by providing extension members that can be used in the scope of the plugins block:

plugins {
    java
    application
}

This should give users the following benefits:

• content-assist for applying plugins (typing <CTRL+SPACE> within the plugins block would cause the IDE to present a list of available plugins)
• a starting point for navigating their docs directly in the IDE

A standalone Kotlin example

fun buildscript() {
    plugins {
        java
        application
    }
}

// Plugins block
fun plugins(setup: PluginsBlock.() -> Unit) {
}

class PluginsBlock {
    fun id(id: String): PluginId = PluginId(id)
}

data class PluginId(val id: String)

// Builtin plugin ids as extension members
val PluginsBlock.java: PluginId
    get() = id("java")

val PluginsBlock.application: PluginId
    get() = id("application")

Alternatively an infix + operator could be used as syntactic hook if the UX is considerably improved:

class PluginBlock { // same as above plus
    // Provides a syntactic hook for content-assist
    operator fun PluginId.unaryPlus(): PluginId = this
}

plugins {
  +application
}

[oehme]

How will this play with our plan to remove all plugins from the distribution itself? How would this help with community plugins? Wouldn't adding yet another syntax just for core plugins add more confusion than benefit?

[bamboo]

Q. How will this play with our plan to remove all plugins from the distribution itself?

There would still exist a curated list of plugins somewhere. The extensions would be generated off of that list.

Q. How would this help with community plugins?

This issue is specifically about builtin plugins but a similar solution could (and should) be provided for community plugins.

Q. Wouldn't adding yet another syntax just for core plugins add more confusion than benefit?

It's not really another syntax for there's no plugins syntax currently (unless you are comparing this to the Groovy DSL). We can design one that accommodates both types of plugins nicely.

The tradeoffs here are very similar to the ones related to dependency configurations and in that case we decided it made sense to provide extensions for commonly used configurations.

[oehme]

There would still exist a curated list of plugins somewhere. The extensions would be generated off of that list.

Just some future considerations: If we really follow through on our modularization goals, that list might be different from distribution to distribution (e.g. "Gradle for Java developers" vs. "Gradle for native developers"). So you might have to generate the extensions as part of the distribution-building process or at runtime. Otherwise you'd risk proposing plugins which then fail to resolve.

This issue is specifically about builtin plugins but a similar solution could (and should) be provided for community plugins.
It's not really another syntax for there's no plugins syntax currently (unless you are comparing this to the Groovy DSL). We can design one that accommodates both types of plugins nicely.

I wasn't aware that there is no plugins block for Kotlin yet. I think we should use our existing API, possibly enhanced with Kotlin-sugar.

The tradeoffs here are very similar to the ones related to dependency configurations and in that case we decided it made sense to provide extensions for commonly used configurations.

Does that mean we auto-complete configurations that are not available? E.g. if I don't apply any plugin I get a proposal for compile? I guess it's a matter of taste, but I'd find it confusing if my IDE proposes things which are an error at runtime.

[bamboo]

So you might have to generate the extensions as part of the distribution-building process or at runtime. Otherwise you'd risk proposing plugins which then fail to resolve.

Yes, the closer we can make static typing predict runtime behaviour, the better. But it's not like stringly-typed plugin ids couldn't fail to resolve as well, right?

Does that mean we auto-complete configurations that are not available? E.g. if I don't apply any plugin I get a proposal for compile?

Yes.

[oehme]

But it's not like stringly-typed plugin ids couldn't fail to resolve as well, right?

Yes, but the tooling didn't propose them to me. Many people have very high trust in what their IDEs tell them to do (through completion). Proposing things that are not actually there might surprise them.

[oehme]

I think we should separate this story from implementing the basic plugins DSL. Having the plugins block is important. Having sugar for core plugins is convenient, but should not block 1.0 in my opinion.

[cypressious]

The infix/operator notation + application won't work because infix/operators always need an explicit left-hand side. The implict receiver won't do it.

[bamboo]

@cypressious there's also the unaryPlus() operator which can be overloaded per context, see for example how it's used in this test case: https://github.com/gradle/gradle-script-kotlin/blob/24d2ab2072e53a68a6e7faf07a79c23f32d339db/src/test/kotlin/org/gradle/script/lang/kotlin/support/DefaultSourcePathProviderTest.kt#L16

That operator is defined here: https://github.com/gradle/gradle-script-kotlin/blob/24d2ab2072e53a68a6e7faf07a79c23f32d339db/src/test/kotlin/org/gradle/script/lang/kotlin/FolderBasedTest.kt#L30