could I get some feedback on <https://github.com/g...
# kotlin-dsl
e
could I get some feedback on https://github.com/gradle/gradle/pull/20790?
❤️ 1
c
This is cool. imo, items like this should be enabled by default. Anything that helps with better APIs!
v
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.
The plugin publish plugin could switch it on maybe though.
t
@Vampire IIUC, it's not about enabling
explicitApi()
but making precompiled script plugins compatible with
explicitApi()
c
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.
e
@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
f
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. 😞
v
@ephemient the comment was not regarding your changes, cut regarding Chris comment that this option should be on by default.
e
ah. turning on
explicitApi()
by default would be a pretty breaking change, but maybe in some future version…
I actually tried making the generated plugin adapter
internal
at first - it would be an ABI break, but hopefully not too bad in production since who references those classes directly? but it broke lots of tests 😢
f
It actually needs to be public because one can do
apply<GeneratedPluginAdapater>()
or
pluginManager.apply<GeneratedPluginAdapter>()
in a build script or another plugin.
e
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
f
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.
v
Hm, but that seems to be a major IDE bug. From Gradle side it works perfectly fine. Is there an according YouTrack issue already?
f
I didn’t create one, maybe there is but my search fu did not reveal anything. Unless it’s fixed in the latest version…
v
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.
👍 1
f
I'll check tomorrow in the project we have were it always was trouble.
👌 1
Didn’t find the time today, but haven’t forgotten either. It’s a very busy week because of the holiday on Thursday in Germany. I’ll get to it asap. 🙂
I went through all places with IntelliJ 2022.2 EAP and could not find the issue anywhere anymore. Seems that it's a thing of the past and got fixed at some point. 😊
👌 1