This message was deleted.

This is cool. imo, items like this should be enabled by default. Anything that helps with better APIs!

I generally like it for published things, besides that I wouldn't publish Gradle related stuff written in Kotlin. But this should imho not be enabled by default. In the majority of cases you don't use it for published stuff but just within a build. And there the implicit API is fine and more convenient imho.

@Vampire IIUC, it's not about enabling

explicitApi()

but making precompiled script plugins compatible with

explicitApi()

even within a build it prevents fuzzy edges on the API. Would hate to go back later and tweak (possibly considerable amounts of) consuming code that have inadvertently depended on something leaking through.

@Vampire this changes nothing about what is published, it simply makes it so that compilation of precompiled scripts doesn't break if

kotlin.explicitApi()

is enabled in the build

Wanted to contribute this for a while as I stumble upon it over and over again. Many thanks! Sadly I cannot help you with the testing. 😞

@ephemient the comment was not regarding your changes, cut regarding Chris comment that this option should be on by default.

ah. turning on

explicitApi()

by default would be a pretty breaking change, but maybe in some future version…

It actually needs to be public because one can do

apply<GeneratedPluginAdapater>()

or

pluginManager.apply<GeneratedPluginAdapter>()

in a build script or another plugin.

I'd expect it to be more common to use

apply(pluginId)

, since the generated adapter name isn't explicit anywhere - and even goes through some funny transforms, I have plugins where it ends up being

Com_example_build_conventionsPlugin

for example

Yeah, it’s normal that the names end up like this (luckily Kotlin has the ability to rename imports), but you often need the

apply<T>()

route to make IntelliJ auto-completion work when you have a script plugin that depends on a script plugin or you won’t get any auto-completion, everything is red.

Hm, but that seems to be a major IDE bug. From Gradle side it works perfectly fine. Is there an according YouTrack issue already?

I didn’t create one, maybe there is but my search fu did not reveal anything. Unless it’s fixed in the latest version…

Actually it works fine here with 2021.3.2 unless I misunderstood what you mean. I have

baz.gradle.kts

with

plugins { java }

and

foo.gradle.kts

with

plugins { id("baz") }; java { toolchain { languageVersion.set(JavaLanguageVersion.of(11)) } }

and it works just fine.

I'll check tomorrow in the project we have were it always was trouble.