Provided dependencies not seen while running

[muroncloud]

Describe the bug

After upgraded to Metals 1.27.0, running the 'Import build' command automatically adds the parameter '-Dbloop.export-jar-classifiers=sources'. The libraries have all become '-sources.jar'. My project fails to run after compiling with source packages. How can I remove this parameter?

Sbt version: 1.9.7 Metals version: 1.2.0 VS Code version: 1.85.1

Expected behavior

No response

Operating system

Linux

Editor/Extension

VS Code

Version of Metals

1.2.0

Extra context or search terms

No response

[tgodzik]

Thanks for reporting. The only thing that -Dbloop.export-jar-classifiers=sources' does is it adds source jar in addition to normal jars. Source packages are not used for compilation, so this couldn't have broken anything.

The libraries have all become '-sources.jar'.

This is recent change and it only influences the Metals view, nothing else.

What is the compilation error you are encountering? This might be related to changes in Bloop, you can set it's version to 1.5.11 and reimport to see if that helps. metals.bloopVersion setting in user settings.

[muroncloud]

Settingmetals.bloopVersion to 1.5.11 prompts:

You have Bloop 1.5.11 installed and Metals requires at least Bloop 1.5.13.
If you installed bloop via a system package manager (brew, aur, scoop), please upgrade manually.
If not, select "Turn off old server". A newer server will be started automatically afterwards.

You will also need to remove or update the `bloopVersion` setting

---

Metals doctor displays when using Bloop 1.5.13:

There are no errors during compilation. However, during debugging, a java.lang.NoClassDefFoundError is reported, and Bloop prompts to click for details on the content above

rcompiler-error(flinkx-build)_14-33-03-666.md

[tgodzik]

To use Bloop 1.5.11 you need to use the Restart build server, you can ignore the warning. Though in you case rerunning build import with that version of Bloop should fix things. There is a recent change that make the debug run with the runtime classpath. This wasn't the case previously in Bloop, so if you added something to a Runtime scope, it could be missing some classes when running with normal classpath.

It seems like in your case it might cause some issues, though it shouldn't. Is it a project we can take a look at? What class are you trying to run?

The compiler error is not related to your issues,

[muroncloud]

I tested and found that for libraries marked with provided, I cannot reach the classes inside them during debugging.

[tgodzik]

That's interesting. The provided classes should not be available on the classpath by default, so that seems like the correct behaviour. Unless I am mistaken here :thinking:

[muroncloud]

The provided scope is applicable during both the compilation and testing phases, As shown in the above image, this implies that these libraries are typically already present in the production environment but are not included in the local development environment. Therefore, I believe these libraries should be visible during local debugging.

[tgodzik]

I need to check out the current behaviour in Bloop then and how we can fix it. You could try running Switch build server command to use sbt directly. Might work better in your case in the meantime.

[tgodzik]

I tried adding provided manually in Bloop when exporting from sbt, but it seems quite problematic to do (haven't figured how to do that). It's also probably related to https://github.com/sbt/sbt/issues/3733

Previously, we were using compile classpath for running, which was also problematic, but worked for your case.

Also, looks like they explicitly write that A dependency with this scope is added to the classpath used for compilation and test, but not the runtime classpath, so the current behaviour is correct while still inconvenient.

Adding it to runtime scope would probably work here as a workaround. I don't think we'll be able to fix this currently, sorry about it. I will open an issue in Bloop since it needs to be done that, however we would need someone much better at sbt to fix this.