By updating to kotlin 1 4 30 and using the `watchos`

Question

< sam> By updating to kotlin 1 4 30 and using the `watchos` shortcut you have effectively removed watchosx86 Can you remove the shortcut and add the separate watchos targets manually

sam · Answer

It was removed because jetbrains changed the watchos and hadn t published a coroutines that was compatible

sam · Answer

I think they may have released an updated coroutines yesterday

Paul Woitaschek · Answer

I think you have it mixed up

Paul Woitaschek · Answer

If I understand correctly they published x86 but not x64

Paul Woitaschek · Answer

But by using the shortcut you don t publish the x86 any longer

sam · Answer

I think in 4 4 1 we didn t publish any watchos pending the the coroutines update

Paul Woitaschek · Answer

You have

Paul Woitaschek · Answer

Paul Woitaschek · Answer

Paul Woitaschek · Answer

This one is missing now because the `watchos ` shortcut doesn t include it any more

sam · Answer

Ok but didn t they deprecate one watchos in 1 4 30 and introduce another target

Paul Woitaschek · Answer

Yes they did

sam · Answer

Can you make a PR to add the appropriate targets not using the shortcuts And I can release

Paul Woitaschek · Answer

Will do

sam · Answer

awesome

Paul Woitaschek · Answer

< sam> I don t like copy pasting the code all over the place I d go with a refactor to use a plugin d accord

sam · Answer

Yep

Paul Woitaschek · Answer

Running into strange gradle issues confused

Paul Woitaschek · Answer

dependencies implementation org jetbrains kotlin kotlin gradle plugin 1 4 31 implementation org jetbrains kotlin kotlin compiler embeddable 1 4 31 When I add this to the buildSrc build gradle it can t resolve the projects any longer Any idea on that

Paul Woitaschek · Answer

I think its because of different kotlin versions bundled to gradle confused

Paul Woitaschek · Answer

Would you be fine with a groovy file that s applied

sam · Answer

Yes

christophsturm · Answer

why do you need kotlin compiler embeddable in the buildSrc build file

Paul Woitaschek · Answer

So I can configure the `KotlinMultiplatformExtension` from the plugin

christophsturm · Answer

in the build file you just declare the dependency on the gradle dsl for example like this ```plugins `kotlin dsl` `kotlin dsl precompiled script plugins` repositories gradlePluginPortal so that external plugins can be resolved in dependencies section mavenCentral dependencies hotfix to make kotlin scratch files work in idea implementation kotlin script runtime ```

christophsturm · Answer

and then you can create a buildSrc src main kotlin myPlugin gradle kts file and put everything there for example ```plugins java `maven publish` signing java Suppress UnstableApiUsage withJavadocJar Suppress UnstableApiUsage withSourcesJar signing sign publishing publications pub ```

christophsturm · Answer

so you would put the dependencies and the plugin in that file and not into the build file or does that not work with the multiproject plugijn

christophsturm · Answer

in buildSrc build gradle kts you can t use a newer kotlin plugin but in the src main build file you can do what you like

Paul Woitaschek · Answer

I tried that already but that s leads to weird issues itself

Paul Woitaschek · Answer

Now a sync either fails with e home paul repos kotest buildSrc src main kotlin kotest multiplatform gradle kts 9 1 Unresolved reference None of the following candidates is applicable because of receiver type mismatch public fun DependencyHandler kotlin module String version String = Any defined in org gradle kotlin dsl public fun PluginDependenciesSpec kotlin module String PluginDependencySpec defined in org gradle kotlin dsl

Paul Woitaschek · Answer

And every third sync fails with Caused by org gradle api plugins UnknownPluginException Plugin id org jetbrains kotlin multiplatform was not found in any of the following sources