/gradle-script-kotlin

New issue

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

Closed
bamboo opened this Issue Oct 25, 2016 · 8 comments

Assignees

@bamboo bamboo

@eskatos eskatos

Labels

a:feature in:gsk-api re:ease-of-use re:plugin-support

Projects

None yet

Milestone

  0.6.0

4 participants

@bamboo @oehme @cypressious @eskatos
@bamboo
Member
bamboo commented Oct 25, 2016 • edited

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
}
@bamboo bamboo added this to the 1.0.0 milestone Oct 25, 2016
@oehme
Member
oehme commented Oct 25, 2016 • edited

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
Member
bamboo commented Oct 25, 2016

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
Member
oehme commented Oct 25, 2016 • edited

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
Member
bamboo commented Oct 26, 2016

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
Member
oehme commented Oct 26, 2016

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
Member
oehme commented Oct 29, 2016

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
cypressious commented Nov 22, 2016

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
Member
bamboo commented Nov 22, 2016

@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
@bamboo bamboo modified the milestone: 0.6.0, 1.0.0 Nov 24, 2016
@bamboo bamboo changed the title from Type-safe, tooling-friendly application of builtin plugins within the plugins block to Builtin plugins can be applied via a type-safe, tooling-friendly mechanism Nov 24, 2016
@bamboo bamboo added a commit that referenced this issue Dec 1, 2016
@bamboo bamboo Generate builtin plugin id extensions 
See #168
This commit was signed with a verified signature.
@bamboo bamboo Rodrigo B. de Oliveira
GPG key ID: EA985E2951C6884A Learn about signing commits
787f5b2
@bamboo bamboo added a commit that referenced this issue Dec 2, 2016
@bamboo bamboo Use the plugins block wherever possible 
See #168
This commit was signed with a verified signature.
@bamboo bamboo Rodrigo B. de Oliveira
GPG key ID: EA985E2951C6884A Learn about signing commits
43b1127
@bamboo bamboo added a commit that referenced this issue Dec 5, 2016
@bamboo bamboo Keep builtin plugin extensions at the PluginDependenciesSpec level 
See #168
This commit was signed with a verified signature.
@bamboo bamboo Rodrigo B. de Oliveira
GPG key ID: EA985E2951C6884A Learn about signing commits
0e189af
@bamboo bamboo added a commit that referenced this issue Dec 5, 2016
@bamboo bamboo Include link to the user guide in builtin plugin extensions 
See #168
This commit was signed with a verified signature.
@bamboo bamboo Rodrigo B. de Oliveira
GPG key ID: EA985E2951C6884A Learn about signing commits
799d81f
@bamboo bamboo closed this Dec 9, 2016
@bamboo bamboo added a commit that referenced this issue Dec 13, 2016
@bamboo bamboo Don't generate extensions for fully qualified builtin plugin ids 
Until we take a decision on what to do about remote plugins (#185).

See #168
This commit was signed with a verified signature.
@bamboo bamboo Rodrigo B. de Oliveira
GPG key ID: EA985E2951C6884A Learn about signing commits
8e5311b
@bamboo bamboo referenced this issue Dec 15, 2016
Closed

Reduce noise for plugin application and configuration methods #58

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment