TL;DR: A mavenLocal dependency accessible to IntelliJ projects fails to resolve correctly when used in Kotlin Notebook. Why?
I have a local Kotlin dependency com.rough4:rough4:0.0
which, for illustration purposes, exposes a println-duplicate myPrintln(msg:String)
in global scope. The dependency is built and published to the mavenLocal
repository (at /home/user/.m2/repository
with the jar being at /home/user/.m2/repository/com/rough4/rough4/0.0/rough4-0.0.jar
).
//rough4/build.gradle.kts
plugins {
kotlin("jvm") version "2.0.0"
`maven-publish`
}
group = "com.rough4"
version = "0.0"
repositories {
mavenCentral()
mavenLocal()
}
kotlin {
jvmToolchain(21)
}
java{
withSourcesJar()
withJavadocJar()
}
publishing{
publications {
create<MavenPublication>("Testing"){
from(components["java"])
}
}
}
//rough4/src/main/kotlin/localFuncs.kt
fun myPrintln(msg:String){
println(msg)
}
When used in a canonical IntelliJ project (with matching jvmToolchain
version and gradle version 8.5) via dependencies { implementation("com.rough4:rough4:0.0") }
, the rough4
dependency resolves and I am able to use myPrintln
. This indicates that the publication process is working correctly.
However, it fails to resolve when added into a Kotlin Notebook via
//annotation based syntax
@file:Repository("*mavenLocal")
@file:DependsOn("com.rough4:rough4:0.0")
import myPrintln
//Line_3.jupyter.kts (4:8 - 17) Unresolved reference: myPrintln
I have tried using @file:Repository("/home/user/.m2/repository")
with and without file://
as well as the gradle-like syntax - nothing works.
//gradle based syntax
USE{
repositories {
mavenCentral()
mavenLocal()
}
dependencies { implementation("com.rough4:rough4:0.0") }
}
What is going on?
Strangely, adding the dependency to the enveloping project's build.gradle.kts (the IntelliJ project in which the Kotlin Notebook was made and opened, instead of it say, being opened outside and independently via jupyter CLI), makes it automatically available in the Kotlin Notebook, in which myPrintln
then becomes accessible.
Most likely, the problem is that the symbol you're requesting is inside the root package. And there is a corresponding bug. https://youtrack.jetbrains.com/issue/KTNB-709/Symbols-from-the-root-package-inside-the-libraries-are-not-resolved-on-the-kernel-side
Workaround: move the symbol to non-root package