New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 participants
@bamboo
Member

bamboo commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Oct 25, 2016

Member

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?

Member

oehme commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bamboo

bamboo Oct 25, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Oct 25, 2016

Member

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.

Member

oehme commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bamboo

bamboo Oct 26, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Oct 26, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Oct 29, 2016

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@cypressious

cypressious 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.

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 bamboo modified the milestones: 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 added a commit that referenced this issue Dec 1, 2016

bamboo added a commit that referenced this issue Dec 2, 2016

bamboo added a commit that referenced this issue Dec 5, 2016

bamboo added a commit that referenced this issue Dec 5, 2016

@bamboo bamboo closed this Dec 9, 2016

bamboo added a commit that referenced this issue Dec 13, 2016

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment