kotlin-language-server icon indicating copy to clipboard operation
kotlin-language-server copied to clipboard

Unresolved reference

Open vito-c opened this issue 5 years ago • 11 comments

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"
      },

image

I can share more of the log with you if you need it. I'm using 2f7d008

vito-c avatar Mar 21 '19 21:03 vito-c

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 avatar Mar 22 '19 11:03 fwcd

@fwcd yah I have tried that. I closed and opened it several times output.log

vito-c avatar Mar 22 '19 16:03 vito-c

{
  "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?

fwcd avatar Mar 22 '19 16:03 fwcd

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?

vito-c avatar Mar 22 '19 17:03 vito-c

Yup, the codebase has recently been split up into modules with the executable being the server module.

fwcd avatar Mar 22 '19 17:03 fwcd

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 avatar Mar 26 '19 14:03 kristianmandrup

@kristianmandrup Yup, currently a build tool is required to use the language server. See #95, or, more specifically, #93.

fwcd avatar Mar 27 '19 00:03 fwcd

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 avatar Jan 28 '20 10:01 krgn

@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.

bogomolov-a-a avatar May 07 '20 20:05 bogomolov-a-a

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.

msoucy avatar Dec 29 '21 01:12 msoucy

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.

fw623 avatar Apr 26 '23 17:04 fw623