I'm trying 2.0.0-RC1: ```kotlin { jvm { withJ...

# k2-adopters

[CLOVIS]

I'm trying 2.0.0-RC1:

kotlin {
    jvm { withJava() }

    sourceSets.commonMain.dependencies { … }
    sourceSets.commonTest.dependencies { … }
}

and I'm getting

> Configure project :app
w: The following Kotlin source sets were configured but not added to any Kotlin compilation:
 * commonMain
 * commonTest
You can add a source set to a target's compilation by connecting it with the compilation's default source set using 'dependsOn'.
See <https://kotl.in/connecting-source-sets>

Did something change in the way platforms are declared? This should definitely generate a jvmMain which depends on commonMain .

[dmitriy.novozhilov]

cc @tapchicoma

[Oliver.O]

Do you use the Compose Multiplatform Gradle plugin in that project? If so, make sure you’re using 1.6.2.

[CLOVIS]

Yes, and yes that is the version I'm using.

[Oliver.O]

I suspect that there is some change in RC1 causing incompatibilities with plugins interacting with KMP. So maybe there’s another plugin causing this.

[CLOVIS]

This project also has the `application`plugin, but I don't believe this is one that should interact with KMP? It also has a bunch of custom-built plugins, but I don't believe they do much magic.

[CLOVIS]

The project itself is public, but it's far from being minimal so I don't know how useful it would be to share here...? https://gitlab.com/opensavvy/automation/gradle-conventions/-/blob/k2/examples/kotlin/app/build.gradle.kts

If there are Gradle features you suspect to cause this, please tell me and I'll search for you :)

[Oliver.O]

Looking just at the build script, I don’t see anything obvious. I have abandoned convention plugins a long time ago, so I can’t really offer meaningful advice on those. At the time I still had them, I always found it a bit tricky to make everything behave properly with KMP.

[CLOVIS]

I'm curious what you have replaced them with. I've set these up a year or so ago, and so far they work great. I'm not sure where to start to understand what's wrong here.

[Oliver.O]

I’ve replaced them with compiled plugins and put those in a local repository.

[CLOVIS]

I think you meant precompiled script plugins then, because what you're describing still fits the convention plugin definition... And this is also what this repository is.

[Oliver.O]

I’ve replaced plugins in buildSrc with regular custom-made plugins. Ok, if you call both variants convention plugins I have misunderstood your project. Then the next thing I’d assume causing this is Gradle’s lazy evaluation which makes reasoning about what’s available when so hard.

[tapchicoma]

I don't such error with code snippet from the topic start message in my test project 🤔

[CLOVIS]

Do you have any prominent suspects that could cause this? It's going to take some time to bisect this thing 😓

[tapchicoma]

nope, could you share a build scan with error?

[CLOVIS]

Here you go: https://scans.gradle.com/s/5zybzu2oew7we

[tapchicoma]

hm, there is no such warning in the console log. Where do you see it?

[CLOVIS]

If you want to run it yourself, the project is public:

git clone <https://gitlab.com/opensavvy/automation/gradle-conventions.git>
cd gradle-conventions
git switch k2
./gradlew -p examples/kotlin --include-build ../.. app:run --scan

Sorry for the invocation method, this is a canary build used to test new plugin versions

[CLOVIS]

hm wait you're right, it didn't trigger on this machine.

[CLOVIS]

I'll try again tonight on the original machine, sorry

[CLOVIS]

Could this be a configuration cache problem? That's the only reason I see why it would behave on these two machines, they are otherwise very similar, but I haven't opened the project in a long time on this one.

[CLOVIS]

Or maybe they have a different JDK version 🤔

[tapchicoma]

CC you could check locally right now 🙂

[tapchicoma]

I doubt JDK version mismatch will affect it

[CLOVIS]

I tried it again on all my machines, and the problem doesn't appear anymore. No idea what is was, but well, as long as it works 😅