Skip to content

Commit a932caa

Browse files
Remove split in jvm source sets and compilations (#4344)
This seems to have been used to test that the core can compile against 1.6 JVM target, but since coroutines jvm jar ships all classfiles for jvm 1.8+ since 1.5.0 This clean up is needed to promote KotlinCompilation.source API to an error deprecation ^KT-64991 Co-authored-by: Timofey Solonin <[email protected]>
1 parent b1711eb commit a932caa

File tree

4 files changed

+2
-58
lines changed

4 files changed

+2
-58
lines changed

kotlinx-coroutines-core/build.gradle.kts

+2-58
Original file line numberDiff line numberDiff line change
@@ -25,43 +25,15 @@ apply(plugin = "pub-conventions")
2525
wasmWasi --------------------> jsAndWasmShared ----------+
2626
|
2727
V
28-
jvmCore\ --------> jvm ---------> concurrent -------> common
29-
jdk8 / ^
30-
|
28+
jvm ----------------------------> concurrent -------> common
29+
^
3130
ios \ |
3231
macos | ---> nativeDarwin ---> native ---+
3332
tvos | ^
3433
watchos / |
3534
|
3635
linux \ ---> nativeOther -------+
3736
mingw /
38-
39-
40-
Explanation of JVM source sets structure:
41-
42-
The overall structure is just a hack to support the scenario we are interested in:
43-
44-
* We would like to have two source-sets "core" and "jdk8"
45-
* "jdk8" is allowed to use API from Java 8 and from "core"
46-
* "core" is prohibited to use any API from "jdk8"
47-
* It is okay to have tests in a single test source-set
48-
* And we want to publish a **single** artifact kotlinx-coroutines-core.jar that contains classes from both source-sets
49-
* Current limitation: only classes from "core" are checked with animal-sniffer
50-
51-
For that, we have following compilations:
52-
* jvmMain compilation: [jvmCoreMain, jdk8Main]
53-
* jvmCore compilation: [commonMain]
54-
* jdk8 compilation: [commonMain, jvmCoreMain]
55-
56-
Theoretically, "jvmCore" could've been "jvmMain", it is not for technical reasons,
57-
here is the explanation from Seb:
58-
59-
"""
60-
The jvmCore is theoretically not necessary. All code for jdk6 compatibility can be in jvmMain and jdk8 dependent code can be in jdk8Main.
61-
Effectively there is no reason for ever putting code into jvmCoreMain.
62-
However, when creating a new compilation, we have to take care of creating a defaultSourceSet. Without creating the jvmCoreMain source set,
63-
the creation of the compilation fails. That is the only reason for this source set.
64-
"""
6537
========================================================================== */
6638

6739
kotlin {
@@ -109,35 +81,7 @@ kotlin {
10981
}
11082
}
11183

112-
/**
113-
* See: https://youtrack.jetbrains.com/issue/KTIJ-25959
114-
* The introduction of jvmCore is only for CLI builds and not intended for the IDE.
115-
* In the current setup there are two tooling unfriendly configurations used:
116-
* 1: - jvmMain, despite being a platform source set, is not a leaf (jvmCoreMain and jdk8Main dependOn it)
117-
* 2: - jvmMain effectively becomes a 'shared jvm' source set
118-
*
119-
* Using this kludge here, will prevent issue 2 from being visible to the IDE.
120-
* Therefore jvmMain will resolve using the 'single' compilation it participates in (from the perspective of the IDE)
121-
*/
122-
val jvmCoreMain = if (Idea.active) null else sourceSets.create("jvmCoreMain") {
123-
dependsOn(sourceSets.jvmMain.get())
124-
}
125-
val jdk8Main = sourceSets.create("jdk8Main") {
126-
dependsOn(sourceSets.jvmMain.get())
127-
}
128-
12984
jvm {
130-
compilations.named("main") {
131-
jvmCoreMain?.let { source(it) }
132-
source(jdk8Main)
133-
}
134-
135-
/* Create compilation for jvmCore to prove that jvmMain does not rely on jdk8 */
136-
compilations.create("CoreMain") {
137-
/* jvmCore is automatically matched as 'defaultSourceSet' for the compilation, due to its name */
138-
tasks.getByName("check").dependsOn(compileTaskProvider)
139-
}
140-
14185
// For animal sniffer
14286
withJava()
14387
compilations.create("benchmark") { associateWith(this@jvm.compilations.getByName("main")) }

0 commit comments

Comments
 (0)