I have a multiplatform project that had android an...

# kotest

[Skolson5903]

I have a multiplatform project that had android and ios targets, and I just added jvm(). So now there are two new sourcesets; jvmMain and jvmTest. I'm trying to debug new JVM unit tests in jvmTest (based on StringSpec), but the debugger fails with a
ClassNotFoundException on the test class. I dug through the classpath entries, and the applicable ones listed for the build are:

build\intermediates\java_res\debugUnitTest\out;
    build\tmp\kotlin-classes\debugUnitTest;
    build\intermediates\java_res\debug\out;
    build\tmp\kotlin-classes\debug;

None of these directories have the jvmTest classes in them after running gradle task jvmTestClasses. I dug around, and the unit tests all compiled to here:

build\classes\kotlin\jvm\test

What controls which directories get put in the classpath from the gradle build when doing a run or debug? Is this a Kotest plugin thing, or do I have something wrong in my gradle setup? Thanks in advance for any help. BTW this is AndroidStudio and I'm currently running the snapshot plugin 1.1.0-SNAPSHOT-IC-2019.3

[Skolson5903]

One more tidbit, the jvmMain classes all compiled to here:

build\classes\kotlin\jvm\main

so both directories would need to be on the classpath for the test to run.

[Skolson5903]

I tried editing the classpath entry on the Run Configuration. Module name ioCommon - module classpath local directories

ioCommon\build\intermediates\java_res\debugUnitTest\out;
ioCommon\build\tmp\kotlin-classes\debugUnitTest;
ioCommon\build\intermediates\java_res\debug\out;
ioCommon\build\tmp\kotlin-classes\debug;

Classpath entry in Edit Configurations: "ioCommon_jvmTest" has one local directory in classpath of debugger:

ioCommon\build\classes\kotlin\jvm\main;

Unfortunately it doesn't have

ioCommon\build\classes\kotlin\jvm\test;

for some reason, so test doesn't work by manually changing the classpath entry. No luck there, so outside of adding a gradle hack to copy the compiled classes to one of the subdirs on the module classpath, I'm stuck :-)

[sam]

It should be jvmTest not jvm/test

[sam]

Maybe your gradle config is weird

[Skolson5903]

Still digging - interestingly, right clicking the jvmTest task and clicking debug works correctly, and stops at a breakpoint in a test. It doesn't give me the granularity of picking which test to debug, but if I only have breakpoints in the class to be debugged, all is good. I can use this as a workaround for now, until I figure out where in gradle AS is getting the classpath it uses for the module when a Run Configuration has been set to use the classpath for the module name containing the test. I've listed the classpath directories/files for jvmTest task and it is correct, which makes sense I guess :-).

[sam]

build\classes\kotlin\jvm\test

does seem right actually, that's where kotest's own MPP build puts them

[sam]

If you are executing gradle tasks, kotest doesn't get involved in all in things like classpaths

[sam]

If you are executing via a green play icon, or via a right click run as, then the kotest plugin sets up the run configuration

[Skolson5903]

I'm still building gradle skills 🙂. Is there a project or task api it uses to get the classpath to use? If so I can dump out what's in my setup for whatever that is, then start tracing the issue from there...

[sam]

Gradle's API is super complicated. They have these things called sourcesets and things called configurations. I don't think anyone truly knows the difference 😂

[sam]

So your jvmTest is like a sourceset (I think).

[sam]

All this is managed by the kotlin mpp plugin

[sam]

all the sourcesets are combined to make your classpath. So in the case of jvmTest, it will be combined with commonTest and jvmMain and commonMain to get the full runtime classpath

[Skolson5903]

yeah, totally agree. in the kotlin {jvm{...}} section is where I've been putting println stuff to dump out the source dirs, classpath output dirs, etc. But I haven't tracked down how to access the Compilations I keep reading about

[sam]

In a regular JVM app, these sourcesets are just called test and main

[sam]

No one really knows, there's 200 ways of doing it, and every time you google, you get competing snippets.

[Skolson5903]

Im looking now for how to access the Configurations and compilations 🙂. I SURE don't really know!

[sam]

The worst mistake gradle ever made was building on top of groovy. It ended up with what I think is possibly the worst DSL I've ever used, which is a shame because under the hood gradle is powerful and I like it.

[sam]

I do think adopting Kotlin meant they've been improving things, because the magic has to go away to some extent when you're using a strongly typed language.

[Skolson5903]

Yeah, Im thumbs up on using kotlin scripting, it's been helping me diagnose stuff like this. I never "got" groovy...

[sam]

I've been using gradle for 10 years or so and I still don't really understand sourcesets, configurations, compilations, and so on. Maybe I'm just thick.

[sam]

I do think if gradle had a reasonable DSL to begin with, it would have killed of maven by now

[sam]

Maybe build tools are just hard to get right 🙂 Because SBT is awful as well.

[Skolson5903]

Everybody wants to do everything, often with their own tweaks, I imagine that makes it tough as hell on build system designers to get maximum flexibility out to folks. I don't envy them :-)

[sam]

Yeah I imagine so. It's like that with kotest. Everyone wants their default to be kotest's default

[Skolson5903]

LOL! I totally get that...