kotlin-language-server
kotlin-language-server copied to clipboard
Unresolved reference
All of the dependencies listed in my build.gradle are showing up as unresolved dependencies. dependencies:
dependencies {
implementation 'com.typesafe.akka:akka-actor_2.12:2.5.21'
testCompile 'com.typesafe.akka:akka-testkit_2.12:2.5.21'
testCompile 'junit:junit:4.12'
implementation 'org.jetbrains.kotlin:kotlin-stdlib'
testImplementation 'junit:junit:4.12'
}
From the Client Log:
{
"range": {
"start": {
"line": 7,
"character": 7
},
"end": {
"line": 7,
"character": 11
}
},
"severity": 1,
"code": "UNRESOLVED_REFERENCE",
"source": "kotlin",
"message": "Unresolved reference: akka"
},
I can share more of the log with you if you need it. I'm using 2f7d008
Yes, it would be helpful if you could share more of the log (especially the beginning where the dependency resolution strategy is output).
Newly added dependencies might additionally require a restart of the language server. Have you tried that?
@fwcd yah I have tried that. I closed and opened it several times output.log
{
"jsonrpc": "2.0",
"method": "window/logMessage",
"params": {
"type": 3,
"message": "client Searching for dependencies in workspace root /Users/vito-c/code/kotlin-akka/src/main/kotlin/koala"
}
}
Apparently, the language server searched for dependencies inside of your source folder, not the project directory (/Users/vito-c/code/kotlin-akka/
). What editor (language client) do you use?
I think there is a way to set the workspace dir I'm using https://github.com/autozimu/LanguageClient-neovim ... I pulled master and it looks like kotline-language-server changed to server/build/install/server/bin/server
?
Yup, the codebase has recently been split up into modules with the executable being the server
module.
I created a simple test.kt
file. I can run it just fine from within VSC using Code runner, but the editor complains:
-
Unresolved reference: Arraykotlin(UNRESOLVED_REFERENCE)
-
Unresolved reference: printlnkotlin(UNRESOLVED_REFERENCE)
fun main(args: Array<String>){
println("test")
}
I installed kotlin via brew install kotlin
. I then added set --export PATH /usr/local/opt/ $PATH
to my PATH
. I can confirm that kotlin
binary is present there as a symlink to /usr/local/Cellar
.
I can also run kotlinc
. What could I be missing?
Are there specific configuration options for this plugin such as the path to KOTLIN_HOME
or sth?
$ java -version
java version "10.0.2" 2018-07-17
Aha, the Kotlin Quickstart project works fine, so I must be missing some required setup. A simple .kt
file is not enough?
@kristianmandrup Yup, currently a build tool is required to use the language server. See #95, or, more specifically, #93.
FWIW, I have hacked GradleClassPathResolver.kt
to use a custom gradle classpath task which I had defined so that I can used kotlinc
with all project dependencies, and it seems to work.
Put the following in build.gradle.kts
:
tasks.register("classpath") {
doLast {
// project.configurations.forEach { println(it) }
println(
"build/classes/kotlin/main:" +
project.configurations.getAt("runtimeClasspath").asPath +
project.configurations.getAt("testRuntimeClasspath").asPath
)
}
}
Then readDependenciesViaGradleCLI
should become:
private fun readDependenciesViaGradleCLI(projectDirectory: Path, gradleScripts: List<String>, gradleTasks: List<String>): Set<Path> {
LOG.info("Resolving dependencies for '{}' through Gradle's CLI using tasks {}...", projectDirectory.fileName, gradleTasks)
val command = "gradle --quiet classpath"
val dependencies = findGradleCLIDependencies(command, projectDirectory)
?.also { LOG.info("Classpath for task {}", it) }
.orEmpty()
return dependencies
}
And parseGradleCLIDependencies
will be a simple String::split
on :
private fun parseGradleCLIDependencies(output: String): Set<Path>? {
LOG.debug(output)
val artifacts = output.split(":")
.mapNotNull { Paths.get(it) }
.filterNotNull()
return artifacts.toSet()
}
@krgn https://github.com/bogomolov-a-a/kotlin-language-server/commit/5df01b50da53bcf5db26cbae2647844523e5db6e. I forked your repository. This fix sugggets that project has gradle wrapper. I will add OS independence later(path separator). And I fixed "classpath" task, following code
ext.printDependencies = { project->
StringBuilder result=new StringBuilder();
for(String name:project.configurations.getNames())
{
try{
String paths=project.configurations.getAt(name).asPath.trim()
if(paths.isEmpty())
{
continue;
}
result.append(paths)
result.append(";")
}
catch(Exception e)
{
//no op;
}
}
println(result)
}
tasks.register("classpath"){
printDependencies(project)
}
for all subprojects in root build.gradle file. May be this solution will be useful.
Is there any movement on this? For me at least, it seems like it's because the dependencies used in the Gradle subproject are declared in the parent.
I had the same or a similar problem with all external dependencies showing up as unresolved by the language server, despite working correctly when building/running with gradle
. But crucially the gradle wrapper script was faulty and didn't work.
For me, regenerating the gradle wrapper with gradle wrapper
fixed the issue and now the language server functions as intended.