Is it expected that `runtimeClasspath` configurati...

# multiplatform

[r4zzz4k]

Is it expected that runtimeClasspath configurations for JVM targets doesn't contain actual compilation output, only dependencies?
The only way I was able to use application plugin is as follows:

tasks.findByName("run").configure {
    classpath = kotlin.targets.jvm.compilations.main.output + project.configurations.jvmRuntimeClasspath
}

(jvm target is, of course, created like this: fromPreset(presets.jvm, 'jvm'))

[r4zzz4k]

And as soon as I hit "Enter", I suddenly remember about jvmWIthJava, which works out of the box with application plugin.
The question is still of interest, but I'm probably missing something obvious as I'm not very experienced in Gradle.

[Liliia]

I think those two tickets will answer your current and upcoming questions:
• https://youtrack.jetbrains.com/issue/KT-27111
• https://youtrack.jetbrains.com/issue/KT-26256

Also, please make sure that you use the latest available Kotlin plugin: Kotlin 1.3-RC2, 1.3.0-rc-116

[r4zzz4k]

Yeah, I know you are still thinking regarding jvm vs jvmWithJava dilemma as it's mentioned in k-new-mpp-samples repo. And I'm not seeing how the first link is relevant, as I'm not touching deprecated configurations (actually my question is still relevant for one multiplatform module with plain Java dependencies).

From what I'm seeing in Gradle Java plugin docs, runtimeClasspath is the configuration which should contain everything needed to run the component, that is both component's compiled classes and all runtime dependencies (provided both by runtimeOnly and by api / implementation). And if I manually do resolve() for all jvmRuntimeClasspath in afterEvaluate block, I'm seeing only dependencies there. So I had to include main compilation's output manually.

So my question was, is that expected behavior or am I understanding something wrong.

I'm playing with 1.3.20-dev-556, if that's important.

[h0tk3y]

Thanks for pointing that out! In fact, it's not entirely correct, and in the Java plugin's model, there's a difference between the runtimeClasspath configuration and a source set's runtimeClasspath file collection. The former only includes the dependencies while the latter contains the source set's output as well. In the new multiplatform plugin, the classpath configurations don't contain the outputs either, which is by design. However, we do have an equivalent for the Java source set's runtimeClasspath file collection: it is a target compilation's runtimeDependencyFiles file collection. As I've just checked, it does not contain the compilation's output for production compilations, but it does for test compilations. This is an inconsistency, and I've filed an issue for it: https://youtrack.jetbrains.com/issue/KT-27272

[r4zzz4k]

Oh, that's what caused confusion for me -- I didn't get the fact that these two things are in fact separate from each other. Thanks for pointing that out!

So I really need this:

tasks.findByName("run").configure {
    classpath =  kotlin.targets.jvm.compilations.main.runtimeDependencyFiles
}

and while the bug is present, I can use this:

tasks.findByName("run").configure {
    classpath = kotlin.targets.jvm.compilations.main.output + kotlin.targets.jvm.compilations.main.runtimeDependencyFiles
}

Is that correct?

By the way, is there a chance kotlin-multiplatform will automatically configure run (and probably others) tasks per JVM target when application plugin is present?

I started all this with shadow plugin, which of course doesn't play well with multiplatform right now, but cooperation `kotlin`<>`shadow` should be probably implemented by latter one, while cooperation `kotlin`<>`application` is reasonable thing to expect from kotlin plugin.

[h0tk3y]

Yes, the classpath looks correct. Indeed, supporting application makes sense, here's an issue for it: <https://youtrack.jetbrains.com/issue/KT-27273>

[r4zzz4k]

Cool, thanks!