MainCommandLineProcessor::pluginOptions accessed before thread local parameters have been set

[ileasile]

When I use a scripting compiler in my project, it possibly does not set thread local parameters (maybe because it's not configured via Gradle). In that case I'm getting this exception. Stacktrace is the following (caught inside debug session):
https://gist.github.com/ileasile/2035f523bdc14248e5ce84e7a40747fa

I suggest a simple solution here: just don't throw an exception, but return an empty collection, maybe with logging a warning.

[tschuchortdev]

Can you maybe show me a code snippet of how you are using a scripting compiler with KCT? I'd like to better understand what you're doing. Support for Kotlin script is very rudimentary at the moment.

[ileasile]

@breandan Could you please elaborate a bit?

[breandan]

Sure, I have a Kotlin multiplatform project that uses this library to run a compiler test and @ileasile's Jupyter Kotlin kernel to run an integration test, both of which are included in the same jvmTest dependency configuration, and both of which transitively depend on conflicting versions of KSP. There is some dependency resolution issue that was resolved by upgrading KSP. To avoid future conflicts, I would like to avoid the KSP dependency altogether.

[tschuchortdev]

I think what is happening here is that the kotlin jupyter kernel is doing its best to recreate the compilation environment that the calling code was compiled with and is scanning the classpath for libraries or plugins to load. But since you are calling the jupyter kernel from within the jvmTest configuration, this classpath will contain all the test dependencies and other test classes. Somehow the ComponentRegistrar and CommandlineProcessor from KCT ended up on the classpath used by the jupyter kernel; perhaps you were too inclusive with the library imports in your implementation of JupyterIntegration or perhaps it is just a consequence of how the resources from this library artifact (which contain service definitions) are put on the classpath by Gradle (I don't know how exactly that works).

I will implement the suggestion of @ileasile and print a warning instead, since the classpath thing is not something that can be fixed easily on my part.

[breandan]

Hi @tschuchortdev, thank you very much for investigating this issue! I am still unable to upgrade past 0.11.0-125 of @ileasile's plugin with your library enabled. In case it helps, here are the most recent results of running ./gradlew build --scan with the Kotlin Jupyter Kernel version 0.11.0-150 and version 1.4.9 of the Kotlin Compile Testing library: https://scans.gradle.com/s/mclihlhmsjaoy