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

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.

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.

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.