Metals won't boot with a NoClassDefFoundError #4706
Labels
improvement
Not a bug or a feature, but something general we can improve
installation
Related to how you install Metals
Comments
This might be a case of the wrong version being there. For example I just checked what should be on the classpath for Metals v.0.11.9 and it actually looks like it'll be looking for 0.15.0: |
|
Good idea, but unfortunately, this doesn't change a thing :/ |
|
🤔 alright can you try one more thing. What's the output of the following for you: |
|
I like how optimistic you are about my chance to install cs locally. I'll give it a shot and let you know :) |
Btw just incase the |
|
Sure, but even that is problematic. When I say my setup is hostile, I mean it. I can set the |
|
I started working on a PR that would detect cs/coursier locally so that you can just use a fully bootstrapped launcher: |
tgodzik
added
installation
|
@tgodzik there might be a misunderstanding here. This issue is not about coursier not installing properly, but about Metals not installing properly, in a way that I believe is entirely unrelated to coursier. Metals successfully downloads all of its dependencies (or at least reports it does), it's "just" that it ends up not finding some classes it's expecting on the CLASSPATH. Coursier, here, is a bit of a tangent: @ckipp01 asked me to run it for diagnostics, which I'm struggling to do because the coursier launcher has hard-coded URLs to maven central, which my environment basically blocks. Improving the way Metals downloads coursier is nice and desirable, but, I think, not related to what we're doing here. Unless I'm missing something? |
There are two ways to create bootstrapped launcher in coursier, one is minimal which will try to download all the needed jars from maven central (this is used in metals) and the other one will have everything already contained. For example https://github.com/coursier/coursier/releases/download/v2.1.0-RC2/coursier.jar should not need to download anything. |
|
Ah. Sorry, I wasn't aware of that. By running the command @ckipp01 suggested with that JAR, I'm seeing a bunch of download failures that I'll need to fix manually, such as metals. It's weird that when installing metals through the VSCode installer, this wasn't reported - nor did Metals even seem to think anything was wrong. |
|
Yeah, might be because bootstrapped coursier is lacking a bunch of functionality. That's why I am thinking of allowing users to just use the one on the system and maybe later even makining it download the right one if possible (or printing instructions otherwise) |
|
The But that'd be for future me. Present me has everything he needs for the moment, thank you! Let's see if I can get this to work now. |
|
It's going to take a while - so many versions of mtags that require a few minutes to timeout, a few minutes to manually upload, and repeat... but, in the meantime: while this is definitely going to help, I'm not sure it's going to fix the issue. My problem is that Metals needs some LSP4J class that's not on the CLASSPATH, but none of the dependencies |
|
Ideally that should be included in the dependencies when querying |
|
Ach and you only need the mtags versions that are neccessary for a particular Scala version you are using. |
|
Actually, could you try replacing the coursier used by the extension with the jar you downloaded (~/.vscode/extensions/.../coursier)? It should print everything much easier once the proper jar is used. And faster hopefully. |
|
You'd think so, but |
I've just tried that, absolutely no observed difference... |
Sure but in order for |
|
Ok, I am adding also a way to print all dependencies #4719 I think it should print everything, but I am not 100% sure. That can be run outside the problematic machine and will print a list like: Dependencies... |
|
Right, so I'm done running the command suggested by @ckipp01. It looks successful: But then, when trying to load a project in VS Code (after uninstalling and reinstalling the Metals extension) I get: Happy to try anything else you might need to understand what's going on, but I'm personally way out of my depths here. |
|
This is highly unexpected, looks like the classpath being printed is incomplete and does not contain the LSP Java library. What do you get as output of: |
|
I’ll check asap but is this even going to work? If I specify an infinite ttl and a list of repositories that will timeout on my environment, I feel like I might be setting myself up for a long, long wi |
|
There you go (with some post-processing for anonymization and readability). |
|
Looks like the classpath is indeed missing Are you able to bring in that library maybe if it's not available? It's a transitive library of lsp4j so should be fine |
|
This might be a symptom of me not truly understanding what's going on here. In particular, I do not know what the But. I've had coursier fetch I've ran that mysterious My probably incorrect interpretation here is that this is expected: I guess So I probably just misunderstood what you meant by "bring in that library". |
|
I thought that maybe an error was somehow being swallowed and jsonrpc was not being brought in. Coming back to the topic maybe the artifacts locally are somehow broken and don't refer to transitive dependencies? It seems that jsonrpc does depend on generator and that in term on jsonrpc, so this all should be brought in. And it seems some transitive ones are missing. |
|
Well, I got tired of this, trashed my entire coursier cache and restarted VS Code. I'm getting much further now, although still blocked. At least this time, the problem is pretty clear: bloop installation. Notice how the artifact names are different. I can't help but feel that this is related to sbt/sbt#3410 |
|
Is it when running build import? It should be resolved correctly the same way any other sbt plugin. Just running |
|
This is probably due to how we include the plugin. @nrinaudo if you look into your which is done by default. I'm assuming if this was like sbt-vspp explains, then it'd work. In theory a workaround for you in this case could be to manually make sure the |
|
@ckipp01 that's exactly it, yes. I suspect I could get that step to work by:
This isn't super realistic though: even if step 1 were to be achieved, there's need to be a new version of sbt-bloop published, then a new version of metals depending on that new version of sbt-bloop, then... |
|
Actually, hang on. Does Metals particularly care which version of sbt-bloop is installed, provided it supports the right tasks? Would there really need to be a new release of Metals? |
sbt-vspp is actually already included in the Bloop build I see and has been as of 1.5.4. |
|
Ah, you're right. Manually adding the And on to the next issue: bsp won't start: I'm about ready to give up... |
|
Bloop downloads a bunch of jars and additional files, maybe you can switch to sbt BSP ? |
I'm assuming in that env he's going to hit on the same thing since he needs the plugin to be published also using sbt-vspp, and we don't publish @adpi2 's work on sbt plugin coordinates is going to be o so so sweet to help with all this nonsense. |
|
Maybe I could at least try to see which artifacts? is there a way to start bsp manually, so that I can try and trace what's going on? |
Well from your trace it looks like you have your Bloop files generated so you could try something like And see what happens. 💣 . I think if this would work, then in reality the server should be able to start. |
Is there anything else in the logs? It should say something about unable to download dependencies. Alternatively, there might be a problem creating a Bloop server? Potentially, you should have on your system Bloop deps ( this is for 1.5.5): |
|
Well, installing the bloop CLI is apparently going to take quite a while again - coursier fails, and I'll probably need to manually track down all dependencies and make them available one after the other. I've already spent more time than I had on this today, so I need to give up for a bit. Will get back to you if I manage to make progress. If you'd like to just close this ticket as WONTFIX, that seems fair. My locked down environment is shooting holes in a whole bunch of unrelated tools, it's not at all clear it's to do with Metals. Metals is just the last domino in the sequence. |
It would be great to have Metals work in even most closed down environments, so think it's good to keep the issue open. Thanks for your patience! |
|
Oh no, thank you for being so patient and walking me through this, one baby step at a time! |
|
Managed to get it resolved in a locked down environment! It was not very straightforward, but the last hurdle was bloop-launcher. I noticed that it also does a Coursier fetch. I would add into consideration 2 things that would help getting this running in locked down environments in general:
While this might not be popular, I'd like to float if something like OSGi would begin to make sense in SBT/Bloop/Metals, as process launching across different environments is tricky business. |
|
I'm happy to hear you finally got it all figured out! I'm confident that if you can get it to work in the environment, it will work anywhere 😆 .
That's tricky since the last issues you hit on should in theory be an implementation detail of the build server, and Metals really should even care what build server is being used. In theory you can use any build server that works with your build, it's just that Bloop is chosen by default here. I understand the pain, but I think the more modular approach that Metals takes by is probably something we want to keep. Again, I understand that's tricky in your case, but maybe it's a good indication that some of the other tools in the ecosystem, like Bloop, could also be improved here to work better / log better in these types of situations. Either way, this is great feedback @ScalaWilliam and something we can for sure discuss/think on more. Thanks! |
|
@ckipp01 a couple more details to help get this resolved:
There might be more. At the moment during the debugging, it seems that there's a problem somewhere between |
You actually can. For example Metals will look for a system property
How are you using Bloopgun? Again I think the experience you're sort of looking for here is the Bloop CLI, which is essentially bloopgun. When using this, doing things like
I've never actually launched bloop this way, but instead if the goal is to launch Bloop manually, the using the Bloop CLI would be the recommended way to do this. Then flags like
Again, depending on how you're using this, but if you're using Bloop CLI, this should indeed be happening. The CLI should essentially be being treated as another BSP client.
My comment was much more generic than Bloop. In general yes, any BSP server that is running should be able to be used, as long as it follows BSP discovery and Metals knows how to connect to it. Unfortunately in the case of Bloop, it doesn't follow BSP discovery, which is why Metals has quite a bit of specific stuff just to handle launching Bloop. I'm curious during all this testing, have you instead just given sbt as your BSP server a try? I know there is some issues probably with resolving the Metals sbt plugin, but just using sbt in your scenario may simplify things greatly. We can address the plugin thing to make that easier. |
|
Update that might help out some people: Metals VS Code extension in the latest prerelease will try to find cs or coursier on the PATH and use that. This makes it a bit easier for corporate envs, since we wouldn't need to download coursier jars from Maven Central. Next step would be to have a way to automatically download coursier binaries somehow, which could setup things such as Java etc. |
|
encountered a version of this with metals 0.11.12 on VSCode. Based on @ckipp01 's advice above, I ran $ coursier launch org.scalameta:metals_2.13:0.11.12 -M scala.meta.metals.DownloadDependencies
Exception in thread "main" java.lang.NoClassDefFoundError: scribe/LoggerSupportthe command works fine with 0.11.11. I finally figured out how to downgrade but please let me know if there's a better workaround so I can stay up to date! |
I think you are missing the latest scribe version? We are using https://github.com/outr/scribe/releases/tag/3.11.1 Not sure why it wouldn't just be mentioned by coursier 🤔 |
|
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. |
|
@jpassaro is this is a proxy environment or on a personal machine? |
|
personal! |
|
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.classdoes that mean this is a coursier bug? |
|
Looks like maybe a bug wihj |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When attempting to boot Metals, I get the following error in the logs:
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.0andorg.eclipse.lsp4j:org.eclipse.lsp4j:0.19.0were available in our Maven repository.The text was updated successfully, but these errors were encountered: