https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
r

r4zzz4k

09/28/2018, 5:29 PM
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:
Copy code
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')
)
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.
l

Liliia

09/28/2018, 5:44 PM
I think those two tickets will answer your current and upcoming questions: • https://youtrack.jetbrains.com/issue/KT-27111https://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
r

r4zzz4k

09/28/2018, 6:04 PM
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.
h

h0tk3y

09/28/2018, 6:33 PM
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
r

r4zzz4k

09/28/2018, 6:40 PM
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:
Copy code
tasks.findByName("run").configure {
    classpath =  kotlin.targets.jvm.compilations.main.runtimeDependencyFiles
}
and while the bug is present, I can use this:
Copy code
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.
h

h0tk3y

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

r4zzz4k

09/28/2018, 6:50 PM
Cool, thanks!