Avoid manual imports for plugin extensions

[reitzig]

When configuring a plugin extension, we have to add an import statement to the build script (or use the fully qualified class name). This is inconsistent with Gradle DSL and annoying. It would be good if classes relevant to extensions would be imported automatically.

Assume we use a plugin that registers an extension like so:

project.getExtensions().add(MyExtension.class, "myExtension", extension);

While we'd use it as

myExtension { ... }

in Groovy DSL, here we have to use

configure<MyExtension> { ... }

Expected Behavior

Above code "just works".

Current Behavior

Either import my.package.MyExtension or configure<my.package.MyExtension> is necessary for the script to compile.

Context

Using the standard plugins, this does not occur: apparently, plugins from certain sources are automatically imported. Trying to use a custom plugin in the same way leads to red code. Granted, IDEA proposes the correct fixes.

Plugins written in Kotlin can extend Project to provide an interface similar to the Groovy DSL, but Java-only ones won't have that.

Your Environment

------------------------------------------------------------
Gradle 5.3.1
------------------------------------------------------------

Build time:   2019-03-28 09:09:23 UTC
Revision:     f2fae6ba563cfb772c8bc35d31e43c59a5b620c3

Kotlin:       1.3.21
Groovy:       2.5.4
Ant:          Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM:          11.0.1 (Oracle Corporation 11.0.1+13)
OS:           Linux 4.15.0-47-generic amd64

IDEA 2019.1.2 with Kotlin 1.3.31

[StefMa]

Please checkout the Kotlin DSL basics. When you apply a plugin within the plugins block then no import is required...

On Thu, May 9, 2019, 4:53 PM Raphael R. notifications@github.com wrote:

When configuring a plugin extension, we have to add an import statement to the build script (or use the fully qualified class name). This is inconsistent with Gradle DSL and annoying. It would be good if classes relevant to extensions would be imported automatically.

Assume we use a plugin that registers an extension like so:

project.getExtensions().add(MyExtension.class, "myExtension", extension);

While we'd use it as

myExtension { ... }

in Groovy DSL, here we have to use

configure { ... }

Expected Behavior

Above code "just works". Current Behavior

Either import my.package.MyExtension or configure is necessary for the script to compile. Context

Using the standard plugins, this does not occur: apparently, plugins from certain sources are automatically imported. Trying to use a custom plugin in the same way leads to red code. Granted, IDEA proposes the correct fixes.

Plugins written in Kotlin can extend Project to provide an interface similar to the Groovy DSL, but Java-only ones won't have that. Your Environment

---

Gradle 5.3.1

Build time: 2019-03-28 09:09:23 UTC Revision: f2fae6ba563cfb772c8bc35d31e43c59a5b620c3

Kotlin: 1.3.21 Groovy: 2.5.4 Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018 JVM: 11.0.1 (Oracle Corporation 11.0.1+13) OS: Linux 4.15.0-47-generic amd64

IDEA 2019.1.2 with Kotlin 1.3.31

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gradle/kotlin-dsl/issues/1382, or mute the thread https://github.com/notifications/unsubscribe-auth/ACOBQ66K7WWGHZQZESUQ44DPUQ3INANCNFSM4HL3ITWA .

[reitzig]

Really? Good to know. In fact, I did observe the behaviour with a plugin still under review at the Gradle Plugin Portal, and therefore applied using the buildscript + apply combo.

In reply to your (insert suitable adjective) opening, let's check out the Primer (v5.4.1).

• Section Implicit Imports doesn't mention this.
• Section When you can’t use the plugins {} block doesn't mention this.
• A section on cross-configuring projects contains import statements, but doesn't explain them.

• Section Project extensions and conventions explicitly spells out what happens:

  Note that the IDE can assist you with the required imports, so you only need the simple names of the types, i.e. without the package name part. In this case, there’s no need to import the Test task type as it is part of the Gradle API and is therefore imported implicitly.

  Oh wait. No mention made of the relevance of where the plugin is applied. In fact, this tells me, "yea, you're gonna need imports at some point".

That covers all appearences of "import" in this document. So, where exactly could I have found that information?

[StefMa]

Sry when you saw my comment as invasive. It wasn't ment to.

I refer to the section Understanding when type-safe model accessors are available. (and the following section Understanding what to do when type-safe model accessors are not available).

But you are right that there isn't mentioned explicit the import thing. Maybe we should change this request to something like

Please add the information to the Understanding what to do when type-safe model accessors are not available section that we have to import the classes which are not known by gradle

[reitzig]

Gotcha. Internet communication is fickle. I felt brush-off-RTFM-ed -- which is kind of fair if the manual contains the pertinent information. ;)

Those sections do indeed not mention anything about name resolution. In fact, they seem to suggest that if you use apply instead of plugins { id }, type-safe accessors won't be available at all. I'm not seeing that; this works just fine (with the import):

It does indeed seem to be more of a documentation than a technical issue. That said, if what you say is true (i.e. apply --> import required), is there a technical reason for that or is it more a "nobody bothered to handle it since apply is (going to be) deprecated" kind of situation?

[eskatos]

Type-safe accessors and Kotlin imports are two separate things. If you think the Kotlin DSL documentation should be enhanced in this regard, please open an issue or PR against gradle/gradle.

There's also https://github.com/gradle/gradle/issues/7557 that would allow plugins to contribute to the list of implicit imports.