https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
e
I'm starting to get nervous that it's https://docs.gradle.org/8.0-rc-2/userguide/upgrading_version_7.html#strict-kotlin-dsl-precompiled-scripts-accessors If it is, is there any way to achieve the previous behavior?
a
If you have a reproducer please open an issue, so team can inspect if it’s an expected behaviour or a bug. Since it’s 8.0-RC2 issue it will get attention soon.
m
Feels weird to me to let the consumer choose the detekt version but still apply the plugin. Is that a common thing?
I would have expected either: 1. a property in your plugin extension (
myPlugin { detektVersion.set(foo) }
) (or better see below) 2. "reacting" on a plugin that is already applied (
withPlugin {}
)
v
Option 1 would be hard though. Because when the "myPlugin" is applied it adds the extension and it is not configured to know the detekt version. Should probably more be a 
myPlugin { useDetekt("1.2.3") }
👍 1
☝️ 2
Accessors for the detekt plugin are then not available for the consumer though. But yeah, would also have assumed a 
pluginManager.withPlugin
instead in that case.
How does the consumer "select" the detekt version? Is it "more convenient" than to apply the plugin in the consumer so that your plugin can react to it being applied and then just configure it?
e
Sorry I wasn't so clear. Here's the problem (I didn't push the branch migrating to 8.0 yet; I'll do that soon so it can be reproed) https://github.com/eygraber/gradle-conventions/blob/master/conventions-plugin/build.gradle.kts#L25 I need that dependency on the detekt plugin so that I can use detekt related classes in the convention plugin. If I use 
implementation
it leaks to the user's classpath and if they depend on detekt plugin as well it could override the version they use. The same issue applies to all the other 
compileOnly
dependencies in that file. I'm just using detekt as an example
v
No, I think you were perfectly clear, you just didn't understand what we say. 😄 If someone applies your detekt convention plugin without adding detekt in the intended version to the classpath, your convention plugin does not know which version to apply. So my question again. How do you expect the consumer of your plugin to specify the detekt version to be used?
If you e.g. expect him to add the detekt plugin in the intended version to the classpath, he could as easily apply the detekt plugin. Then your convention plugin can have 
compileOnly
and instead of applying the detekt plugin it can simply react to the fact your consumer applied the detekt plugin using 
pluginManager.withPlugin("io.gitlab.arturbosch.detekt") { ... }
. He could even apply your convention plugin (or all your convention plugins) without applying the detekt plugin and your convention plugin would then simply do nothing, as the 
withPlugin
closure will never be invoked.
➕ 1
e
I prefer if the convention plugin applies the plugin because otherwise the user would have to apply two plugins; detekt and my convention plugin. Some of my projects have hundreds of subprojects so that's a pain. To add detekt to the classpath it's a single line in the root build file.
👍 1
I'll file an issue with my use case, but I do understand why that behavior wouldn't be supported.
m
Some of my projects have hundreds of subprojects so that's a pain.
I see
After updating to Gradle 8.0-rc-2 the plugins that I apply in the precompiled script plugins are no longer found
Might also be a classloader thingie. Are you using 
buildscript {}
by any chance, in which case you could try this?
Copy code
// rootProject/build.gradle.kts
plugins {
 id("io.gitlab.arturbosch.detekt").version(foo).apply(false)
}
e
Just to make sure we're on the same page, the failures are happening when I build my conventions plugin project, not in the projects that consume the convention plugin.
👀 1
m
oohoh well.. then I don't know. I would not have expected this to be checked when doing 
./gradlew -p build-logic build
or so...
e
I'm pretty sure it's because of https://docs.gradle.org/8.0-rc-2/userguide/upgrading_version_7.html#strict-kotlin-dsl-precompiled-scripts-accessors Pre 8.0 there were warnings, but the plugin built correctly.
m
I guess you tried
Copy code
systemProp.org.gradle.kotlin.dsl.precompiled.accessors.strict=false
?
e
I'm about to, but I don't think it'll work (they say they're getting rid of it)
👍 1
m
Probably not the answer you're looking for but you could write your plugin as "plain" Kotlin (without 
kotlin-dsl
). You won't have generated accessors but you'll be able to apply the detekt plugin dynamically I believe
v
Ah, I see. So does it fail during the 
generatePrecompiledScriptPluginAccessors
task? Could well be that this is a bug that the 
compileOnly
dependencies are not added to the dummy projects classpath that is used to generate the accesors.
➕ 1
You could either do like @Martin suggested, or you could not use the 
plugins { ... }
block in your convention plugin but use the legacy 
apply(...)
. Then you also do not get accessors and need to use the more verbose syntax but can keep them as precompiled script plugins.
e
Copy code
systemProp.org.gradle.kotlin.dsl.precompiled.accessors.strict=false
actually worked! I guess it's just deprecated now, but still works? It is happening during 
generatePrecompiledScriptPluginAccessors
v
But yeah, you should open an issue about that. Makes sense to just add it to the classpath using the root build script and just apply the convention plugin in subprojects.
Yeah, I expect that setting to be removed at some point, but probably only in Gradle 9+. But that's just a wild guess.
👍 1
e
thank you 1
⭐ 1
🎉 1
3 Views
Open in Slack
PreviousNext
Powered by