No code navigation when source (and dependency) jar reside in local repo

[p-pavel]

Describe the bug

This was discussed in discord channel

metals-test.zip

Attached is the project including local maven repo. This was created with scala-cli.

running vscode/metals in codeThatUsesRepo does not permit code navigation to the sources contained in local repo.

The problem persists with both scala-cli and bloop used as build server.

Code completion and compiling works ok.

I also tried the following:

moved scala-cli generated build server configuration to .bloop removed .scala-cli .vscode .metals directories restarted vscode, so metals now uses bloop (I checked) as a build server without any notice of scala-cli around.

The situation is the same: everything works (compiling, completion, running) except source navigation.

bloop configs mention correct location for source jar.

Expected behavior

No response

Operating system

macOS

Editor/Extension

VS Code

Version of Metals

1.3.5+58-ead4e2ec-SNAPSHOT

Extra context or search terms

No response

[p-pavel]

While probably not causing the issue by itself, it's worth noting that having hardcoded repositories in JarSourcesProvider is probably not the best solution:

@kasiaMarek

[kasiaMarek]

While probably not causing the issue by itself, it's worth noting that having hardcoded repositories in JarSourcesProvider is probably not the best solution

JarSourcesProvider only serves as a fallback, by default build server should pass sources to Metals. It would be better to get the repositories from the build but I don't think there is a way to get that information from the build server (it isn't a part of the BSP). So this is only a "try something it may work" fallback.

[p-pavel]

While probably not causing the issue by itself, it's worth noting that having hardcoded repositories in JarSourcesProvider is probably not the best solution

JarSourcesProvider only serves as a fallback, by default build server should pass sources to Metals. It would be better to get the repositories from the build but I don't think there is a way to get that information from the build server (it isn't a part of the BSP). So this is only a "try something it may work" fallback.

💯

Agree, that what I said to @tgodzik, but he suggested dropping a note into the issue anyway.

[p-pavel]

Ok. The problem boils down to the fact that here we have completely Scala 3 shop so artefacts are published without scala version postfix (api-sources.jar not api_3-sources.jar).

So the version detected by scala.meta.internal.metals.ScalaVersion.dialectForScalaVersion becomes Scala213Source3 (I'm not sure why). If the jar is published with correct _3 postfix everything works ok.

I'm not sure what the correct behaviour should be in this case, but for us it's easier to republish the jars and make one-line correction to the general build procedure.