Vampire
01/02/2025, 3:14 PMorg.jetbrains.kotlin.multiplatform
and also on embeddedKotlin("compiler-embeddable")
.
The reason is, that one of the plugins applies kotlin("multiplatform")
and another is using
val File.importedFiles: List<File>
get() = if (!isFile) {
emptyList()
} else {
PsiManager
.getInstance(
KotlinCoreEnvironment
.createForProduction(
Disposer.newDisposable(),
CompilerConfiguration().apply {
put(MESSAGE_COLLECTOR_KEY, NONE)
},
JVM_CONFIG_FILES
)
.project
)
.findFile(CoreLocalVirtualFile(CoreLocalFileSystem(), toPath()))
.let { it as KtFile }
.fileAnnotationList
?.annotationEntries
?.asSequence()
?.filter { it.shortName?.asString() == "Import" }
?.flatMap { it.valueArgumentList?.arguments ?: emptyList() }
?.mapNotNull { it.getArgumentExpression() as? KtStringTemplateExpression }
?.map { it.entries.first() }
?.mapNotNull { it as? KtLiteralStringTemplateEntry }
?.map { resolveSibling(it.text) }
?.flatMap { it.importedFiles + it }
?.toList()
?: emptyList()
}
to get the files a given *.main.kts
file imports.
That latter cannot be done as a worker action because this is needed at configuration time to determine the input files for a task that is executing that *.main.kts
file.
But now when I update the Kotlin version to 2.1.0 I get a warning
> w: The artifact org.jetbrains.kotlin:kotlin-compiler-embeddable
is present in the build classpath along Kotlin Gradle plugin.
> This may lead to unpredictable and inconsistent behavior.
> For more details, see: https://kotl.in/gradle/internal-compiler-symbols
when applying that plugin.
As it is a runtime issue, I assume that splitting into multiple plugins would also not help as in the end it would again be in the same runtime classpath.
How would I solve this task in a forward-compatible way, besides putting the logic into a separate Kotlin file or script and executing it as external process instead of in-process, or splitting it into multiple plugins and ensuring those plugins are not applied to the same projects, or relocating the compiler classes into my plugin?mbonnin
01/02/2025, 3:52 PMVampire
01/02/2025, 3:54 PMkotlin-compiler-embeddable
are both in the build script classpath.mbonnin
01/02/2025, 3:55 PMkotlin-gradle-plugin
and kotlin-compiler-embeddable
you'll need to ship different versions of your plugin for different versions of KGPmbonnin
01/02/2025, 3:56 PMkotlin-compiler-embeddable
usages to a differrent classloader so you "should" be fine?Vampire
01/02/2025, 3:56 PMVampire
01/02/2025, 3:56 PMVampire
01/02/2025, 3:56 PMmbonnin
01/02/2025, 3:59 PMThat latter cannot be done as a worker action because this is needed at configuration time to determine the input files for a task that is executing thatIf it's only about input files and does not affect the task graph, can't the computation be moved to a separate task?file.*.main.kts
mbonnin
01/02/2025, 3:59 PMVampire
01/02/2025, 4:01 PMVampire
01/02/2025, 4:03 PMkotlin-compiler
if the needed classes are in there too and hope this is not checked for presence. πmbonnin
01/02/2025, 4:08 PMBesides writing to some file and then reading that file which feels like a crutch in that situation.Yea, paying the serialization price all the time π I wish Gradle had a way to save that if the 2 tasks are part of the same build and the intermediate result is not "interesting". But that sounds like a complicated problem
tapchicoma
01/03/2025, 5:31 PMtapchicoma
01/03/2025, 5:32 PMmbonnin
01/03/2025, 5:34 PMKGP still brings parts of Kotlin compiler into build classpath, so it is not false-positive warningI mean it's fine if the symbols I compile against are compatible with the version used by KGP, right?
Vampire
01/03/2025, 5:35 PMmbonnin
01/03/2025, 5:36 PMtapchicoma
01/03/2025, 5:37 PMI mean it's fine if the symbols I compile against are compatible with the version used by KGP, right?It could be fine or could lead to some cryptic build errors π€·ββοΈ
tapchicoma
01/03/2025, 5:37 PMmbonnin
01/03/2025, 5:38 PMmbonnin
01/03/2025, 5:39 PMtapchicoma
01/03/2025, 5:40 PMVampire
01/03/2025, 5:41 PMNoSuchMethodError
is in 98.7% version conflict / classpath problem πmbonnin
01/03/2025, 5:41 PMtapchicoma
01/03/2025, 5:42 PMNot too cryptic to meYou are quite advanced Gradle user π Imagine this error will see some Gradle newbie
tapchicoma
01/03/2025, 5:42 PMVampire
01/03/2025, 5:43 PMmbonnin
01/03/2025, 5:43 PMmbonnin
01/03/2025, 5:44 PMmbonnin
01/03/2025, 5:45 PMtapchicoma
01/03/2025, 5:49 PMif every plugin start adding custom messages it's going to be a lot of messagesIf every message will have a resolution suggestion and they are gone once issue is resolved - I don't see a big problem here π
Vampire
01/03/2025, 5:49 PMmbonnin
01/03/2025, 5:51 PMIf every message will have a resolution suggestion and they are gone once issue is resolvedI think that's my main gripe with the warning, ultimately, it's only actionable to the
kotlinter
maintainers, right?mbonnin
01/03/2025, 5:53 PMkotlinter
to move to a different classloader (which takes some time because it's no small refactor)Vampire
01/03/2025, 5:57 PMtapchicoma
01/03/2025, 5:58 PMmbonnin
01/03/2025, 5:58 PMmbonnin
01/03/2025, 5:58 PMVampire
01/03/2025, 5:59 PMmbonnin
01/03/2025, 6:00 PMkotlin-compiler-embeddable
is stable, it's also fine to resolve all dependencies in the root build.gradle.ktsmbonnin
01/03/2025, 6:00 PMVampire
01/03/2025, 6:01 PMmbonnin
01/03/2025, 6:02 PMVampire
01/03/2025, 6:02 PMtapchicoma
01/03/2025, 6:12 PMmbonnin
01/03/2025, 7:00 PMVampire
01/21/2025, 4:28 PMcompileOnly
and is then supplied to the isolated worker classpath again.
And another task that uses the worker API to execute the .main.kts
scripts.
Now it all works without that warning and the tasks can also run in parallel
and are more maintainable too due to separating into proper classes. πVampire
01/21/2025, 4:28 PM