Is there anything peculiar to know with the Kotlin...
# gradle
c
Is there anything peculiar to know with the Kotlin Multiplatform plugin when running under Gradle TestKit? What I'm seeing is that if I don't interact with it at all, I get a successful build, however if my plugin uses
Copy code
kotlinExtension.sourceSets.named { it == "jsMain" }.configureEach {
	println("The JS source set exists")
}
then the build fails with
Copy code
> Configure project :core
e: Please initialize at least one Kotlin target in 'core (:core)'.
Read more <https://kotl.in/set-up-targets>

w: The following Kotlin source sets were configured but not added to any Kotlin compilation:
 * commonMain
 * commonTest
where
:core
is just:
Copy code
plugins {
	kotlin("multiplatform")
	id("my.plugin.here")
	id("maven-publish")
}
		
kotlin {
	jvm()
	js(IR) {
		browser()
	}
}
My understanding is that
.named { … }.configureEach { … }
is lazy and thus shouldn't impact the build configuration at all, and certainly not which platforms are declared. I also tried
Copy code
kotlinExtension.sourceSets.configureEach {
    if (it.name != "jsMain") return@configureEach
    println("The JS source set exists")
}
to the same result.
In case that's important, only my plugin is imported from the TestKit classpath. The Kotlin plugin is declared normally in the root build.gradle.kts for the test, with a version number and
apply false
, as usual.
The plugin does work completely fine outside of Gradle Testkit (tested by going into the generated build directory and running
./gradlew check --include-build=../path-to-the-plugin
)
(everything mentioned here is open source, public, and reproducible in Docker, so if this is abnormal I can easily share more details on request)
Uh, it's the Kotlin extension. •
kotlinExtension
extensions.findByName("kotlin")
✔️
extensions.findByType(KotlinProjectExtension::class.java)
extensions.findByName("kotlin") as KotlinProjectExtension
Is it just whenever I mention any symbol from the Kotlin plugin? If so, that's inconvenient 😅
The plugin-under-test has a
compileOnly
dependency on the Kotlin plugin, and the tests are in another dependent module, so it shouldn't be that the plugin is changing the Kotlin version?
The Kotlin plugin is loaded from
build/tmp/tests/work/.gradle-test-kit/caches/module-2/
, so it is injected by Gradle.
Adding an explicit dependency from the test project upon the Kotlin plugin seems to allow me to access symbols from the Kotlin plugin… Yet the plugin is still loaded from the same files. I'm really confused.
a
there's some sort of minor bug with the new
.named {}
filter https://github.com/gradle/gradle/issues/28347 Is there a change if you try
kotlinExtension.sourceSets.matching { it.name == "jsMain" }.configureEach {}
?
c
No, referring to
kotlinExtension
at all causes the problem, even if I access none of its methods, so I don't believe
named
/`matching` is the cause for this.
🤔 1
a
ahh yes, I actually read your follow up messages, and I see what you mean!
j
it works for me with no issues
c
@Javier Do you have a direct dependency from the project that runs TestKit to the Kotlin plugin?
j
yes, and I add it to the test classpath too
c
Does the test still work if you remove it? Gradle should be able to download the kotlin plugin normally, right?
j
I haven’t tried for a while (years)
👍 1
are you adding it to the test classpath?
I am using a mobile phone, but you need to add the Kotlin plugin to a custom configuration and add it to this: https://docs.gradle.org/current/javadoc/org/gradle/plugin/devel/tasks/PluginUnderTestMetadata.html
c
I added a
api
dependency on the Kotlin plugin and didn't need to do this. I believe it's a somewhat recent thing? Not sure.
j
api = “implementation”
with implementation/api the consumer does not need to add the kotlin plugin to the classpath, it is really opinionated if it is for an public project, if it is internal, no problem
c
The tests have their own project which is not published, so it doesn't matter in this case 👍
👍 1
v
there's some sort of minor bug with the new
.named {}
filter
I wouldn't call that "minor", it voids the whole rectification for existence as the exact cause why it was invented does not work but it is just behaving exactly like
matching
. I'd more say this is a major bug at least. 😄
👍 2