https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
If you do the 
tasks.register
, it is probably when that plugin tries to add the task when you get the error that the task already exists, because, well, you registered it first. What you miss is a
Copy code
pluginManager.withPlugin("plugin that registers the task") {
    ...
}
around the try to configure the existing task. Using 
afterEvaluate
is almost always the wrong way.
Or instead of 
pluginManager.withPlugin
you can apply the plugin explicitly first
It's mainly a question of whether you definitely need that plugin if that script plugin is applied or whether you want to configure it in case it was or will be actually applied and do not do the configuration if not.
You should also consider moving those script plugins to be precompiled script plugins. There are quite some shenenigans with script plugins, especially when using Kotlin DSL, like for example not getting type-safe accessors, some class loading quirks, ...
So if you for example make it a precompiled script plugin and apply the plugin in question in its 
plugins { ... }
block, then you also have the type-safe accessor for the task and do not need to get the task by 
String
name.
s
Thanks, I didn't know about the 
withPlugin
construct. But using
Copy code
pluginManager.withPlugin("batect-kotlin") {
still gives 
Task with name 'checkJourneyTestNaming' not found in project ':app'.
And yes, moving those "loose" scripts to 
buildSrc
would be the next step.
v
Are you sure you wait for the correct plugin?
Or is it maybe not a task but an extension? (The type-safety of a precompiled script plugin would greatly help here 😄 )
s
Hmm, should I use the plugin's 
id
, or its name used in the 
create
call?
v
Which 
create
call? The 
id
that you also use to apply the plugin.
s
Ok, by using the name instead of the id it worked, thanks 🙂
v
no, it did not, by using the name the block simply did not execute as no such plugin is applied
s
hmm...
v
But I seem to be right, there is an extension called 
checkJourneyTestNaming
and a task called 
checkJourneyTestNaming
. The old Groovy script configured the extension. The task is registered in 
afterEvaluate
which should actually be fixed. That's the reason you cannot configure the task like you tried. You could probably do 
tasks.withType<JourneyTestNamingCheckTask>().matching { it.name == "checkJourneyTestNaming" }.configureEach { ... }
that should also work with the task registered in 
afterEvaluate
without using 
afterEvaluate
yourself for the price of realizing all tasks of type 
JourneyTestNamingCheckTask
to evaluate the 
matching
. But I think configuring the extension like is done in the Groovy variant is the better solution. And of course fixing 
afterEvaluate
usage in the batect plugin.
s
Thanks for your input!
👌 1
5 Views
Open in Slack
PreviousNext
Powered by