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')

)

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

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.

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

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.

Yes, the classpath looks correct. Indeed, supporting

application

makes sense, here's an issue for it:

<https://youtrack.jetbrains.com/issue/KT-27273>

Cool, thanks!