Metals won't boot with a NoClassDefFoundError

[nrinaudo]

Describe the bug

When attempting to boot Metals, I get the following error in the logs:

2022.12.07 13:03:27 INFO  tracing is disabled for protocol LSP, to enable tracing of incoming and outgoing JSON messages create an empty file at c:\JPMC\DEV\TMP\mep-code-gen-unsealed\.metals\lsp.trace.json or C:\Users\D634183\AppData\Local\scalameta\metals\cache\lsp.trace.json
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/lsp4j/jsonrpc/CancelChecker
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016)
        at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:800)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:698)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:621)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:579)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        at scala.meta.metals.Main$.main(Main.scala:53)
        at scala.meta.metals.Main.main(Main.scala)
Caused by: java.lang.ClassNotFoundException: org.eclipse.lsp4j.jsonrpc.CancelChecker
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 11 more

Expected behavior

I would expect Metals to boot.

Operating system

Windows

Editor/Extension

VS Code

Version of Metals

v0.11.9

Extra context or search terms

Our setup is really rather hostile. On top of running Windows, all Maven requests have to go to an internal repository, which has to be populated manually.

This initially caused troubles far earlier in the installation process (when Metals failed to download its dependencies), but with the help of @tgodzik , I was able to identify which artifacts were missing and make them available.

I suspect the issue is that, somehow, metals is expecting some LSP4J JARs to be on the CLASSPATH but can't find them.

I have made sure that both org.eclipse.lsp4j:org.eclipse.lsp4j.jsonrpc:0.19.0 and org.eclipse.lsp4j:org.eclipse.lsp4j:0.19.0 were available in our Maven repository.

[tgodzik]

I'll try a manual install later, but if it's a declared dependency, why wouldn't coursier have installed it and added it to the classpath?

That's what I don't understand either.

[ScalaWilliam]

@jpassaro is this is a proxy environment or on a personal machine?

[jpassaro]

personal!

[jpassaro]

a bit of investigation after verifying the problem still exists reveals even more mystery: coursier knows the scribe jar is needed and also it is definitely on my disk with the LoggerSupport .class file

$ coursier resolve org.scalameta:metals_2.13:0.11.12 | grep scribe
com.outr:scribe-file_2.13:3.11.1:default
com.outr:scribe-slf4j_2.13:3.11.1:default
com.outr:scribe_2.13:3.11.1:default
$ unzip -l /Users/jpassaro/coursier-cache/https/repo1.maven.org/maven2/com/outr/scribe_2.13/3.11.1/scribe_2.13-3.11.1.jar | grep LoggerSupport
warning [/Users/jpassaro/coursier-cache/https/repo1.maven.org/maven2/com/outr/scribe_2.13/3.11.1/scribe_2.13-3.11.1.jar]:  147456 extra bytes at beginning or within zipfile
  (attempting to process anyway)
     6401  01-01-2010 00:00   scribe/LoggerSupport$.class
    10387  01-01-2010 00:00   scribe/LoggerSupport.class

does that mean this is a coursier bug?

[tgodzik]

Looks like maybe a bug wihj coursier launch, what's your version?