Are official <docs> for creating a custom compilation out of date, or am I doing something wrong? I’...

# multiplatform

[Kirill Zhukov]

Are official docs for creating a custom compilation out of date, or am I doing something wrong? I’m following this configuration exactly but running into problem where my custom configuration jvmIntegrationTest is failing to resolve references from commonMain.

[Kirill Zhukov]

Untitled.kt

Untitled.kt

[Kirill Zhukov]

In my jvmIntegrationTest code getting a bunch of Cannot access class foo where `foo`s are references from commonMain of this exact same module.

[Kirill Zhukov]

Am I missing configuration somewhere to link main compilation to the integration test compilation, or how does this work?

[Kirill Zhukov]

Adding associateWith(main) to compilation doesn’t seem to help

[Kirill Zhukov]

Looks like what I was missing is associateWith(test), wouldn’t that make integrationTest depend on test? - I don’t really want that

[Kirill Zhukov]

Looks like it does compile jvmTest when running jvmIntegrationTest which is not ideal

[Kirill Zhukov]

associateWith(main) might be what I want here actually

[Kirill Zhukov]

But that gets me back to “unresolved reference” issues.

[Kirill Zhukov]

Still having “unresolved reference” issues with associateWith(main). So associateWith ain’t it? Wish associateWith had some docs on it 🙃

[Kirill Zhukov]

Okay… So what I was actually missing is implementation(kotlin("test-junit")) on the `integrationTest`’s default source set… How does this work?

[ephemient]

Kotlin Gradle Plugin automatically adds the dependency to test depending whether the test task uses JUnit 4, JUnit Jupiter, etc.

[ephemient]

doesn't work for other source sets so you get to add it manually

[Kirill Zhukov]

That makes sense… But it’s not clear to me why not having test dependency causes issues where jvmIntegrationTest source set is unable to resolve references from jvmMain source set of that same module 🤔