https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
As I sadi in the Kotlin Slack, you probably register the task first and some plugin you apply registers the task later again or something like that. But hard to tell without seeing your full build. Anyway, you should probably not declare that dependency anyway, as 
test
is not a lifecycle task, and 
test
is most probably not really depending on 
desktopTest
. It would most probably be more appropriate to make 
check
depend on 
desktopTest
.
If you run with 
--stacktrace
or 
--build
you will most probably see, that the second error is coming from some other code, not yours.
You should practically never 
replace
any task anyway, unless you know very very very well what you are doing
v
while this works with check, kotest uses the test method so using it with check does not do anything. This method is a hack job solution because Jetbrains decided that their template for the "stable" kotlin multiplatform is going to not work with the IDE. Because I dont want to wait for them to fix something that should never have been broken, I am forced to resort to these ... unconventional methods to fix my kotest (which is a plugin that is borked by jetbrains "stellar" template)
Let me do a run with --stacktrace, and send the results
v
Well, then make sure you first apply the plugin that registers the 
test
task before you try to configure it and then configure it instead of replacing or recreating it.
If you cannot apply the plugin first, you need to do some reacting instead like 
tasks.matching { it.name == "test" }.configureEach { ... }
If you did make sure the plugin was applied first, you can just do 
tasks.test { ... }
5 Views
Open in Slack
PreviousNext
Powered by