Package Details: metals 0.11.6-4

Git Clone URL: https://aur.archlinux.org/metals.git (read-only, click to copy)
Package Base: metals
Description: Language Server For Scala
Upstream URL: https://scalameta.org/metals/
Keywords: jvm lsp scala
Licenses: Apache
Submitter: isomarcte
Maintainer: isomarcte
Last Packager: isomarcte
Votes: 8
Popularity: 0.000099
First Submitted: 2019-04-10 17:11 (UTC)
Last Updated: 2022-06-17 15:09 (UTC)

Dependencies (8)

Required by (0)

Sources (8)

Latest Comments

jypma commented on 2021-11-19 12:16 (UTC)

Bumping the version to 0.10.9 installs the new version just fine. Just remember to also bump version-fix.patch. I wonder if we can make PKGBUILD inject the version number into there, so there's not two places to edit? I completely overlooked that first, making for a mysteriously non-working install :-)

isomarcte commented on 2020-09-24 02:35 (UTC)

@das_kube I'm unable to reproduce this on 0.9.3-1. Can you try building it with extra-x86_64-build from the devtools package and see if you still have issues? That builds it in a systemd-nspawn container which dramatically reduces the likelihood that anything on the build system (your system, in this case) will effect the build.

das_kube commented on 2020-09-21 13:41 (UTC)

I cannot build the package, version 0.9.3-1 because it fails to retrieve dotty:

[…] [error] (mtags3 / scalaInstance) Couldn't retrieve ch.epfl.lamp:dotty-compiler:0.26.0-RC1. […]

I use jdk11-openjdk if it makes any difference.

Crandel commented on 2020-07-28 09:59 (UTC)

@isomarcte Thank you for a quick fix, now it works

isomarcte commented on 2020-07-27 14:25 (UTC) (edited on 2020-07-27 14:25 (UTC) by isomarcte)

@Crandel this should be fixed now, in version 0.9.2-2.

isomarcte commented on 2020-07-27 13:23 (UTC)

@Crandel I've got a fix for this. I'll do a release in about an hour.

isomarcte commented on 2020-07-27 12:45 (UTC)

@Crandel I'm taking a look at this in the next few hours. If it takes more than a few minutes to fix, you can track progress here. https://github.com/isomarcte/metals-pkgbuild/issues/21

Crandel commented on 2020-07-27 10:09 (UTC)

Metals not working after update to 0.9.2 because of missing some source code according to this issue. Please update PKGBUILD

Musikolo commented on 2020-01-14 00:28 (UTC) (edited on 2020-01-14 00:29 (UTC) by Musikolo)

Why after install this package VS Code still shows the "Downloading metals v0.8.0" message which gets multiples JARS under $HOME/.cache/coursier?

Isn't it supposed this package to bundle all those JAR files?

I know I'm missing something, but I don't know what... :-/

isomarcte commented on 2020-01-13 21:31 (UTC) (edited on 2020-01-13 21:44 (UTC) by isomarcte)

@Crandel it's not a typo. 0.7.6 did not build with JDK 11, but it did run with JDK 11. 0.8.x should build and run though.

See https://github.com/scalameta/metals/pull/1171

I'm getting it updated for 0.8.x now.

Crandel commented on 2020-01-13 17:07 (UTC)

There is a typo in PKGBUILD. For building you could use jdk11, but it require < 11

isomarcte commented on 2019-12-05 00:15 (UTC)

@Crandel sorry that took a bit longer. 0.7.6-2 now allows you to specify the JDK to run with using the METALS_JDK_PATH environment variable, but defaults to 11, then 10, then 8 in that order.

isomarcte commented on 2019-11-25 23:00 (UTC)

Can you update java-environment=8 to java-environment=11. Java 11 is supported right now based on this issue https://github.com/scalameta/metals/issues/762

Yes, I've been meaning to do that for some time. I'll see if I can get to it today.

ckipp01 commented on 2019-11-25 18:38 (UTC)

It's very odd that metals needs to know what client your using when the whole point of a language server is to be client agnostic.

We actually use this for a few different reasons. Not all clients respect LSP the same way, which causes us to have to rely on what is set as that variable. Also, LSP is extensible, which allows us to build custom LSP extension, our tree view protocol for example https://scalameta.org/metals/docs/editors/tree-view-protocol.html, and not all editors support those extensions. Another reason is that certain editors interpret the same command a bit different. For example, VS Code will add a "magic" indent when you send a textEdit from the server to the client, but emacs won't. So, we use that variable to provide a better user experience for the end user. :)

Crandel commented on 2019-11-25 13:18 (UTC)

Can you update java-environment=8 to java-environment=11. Java 11 is supported right now based on this issue https://github.com/scalameta/metals/issues/762

cheezsteak commented on 2019-09-11 14:56 (UTC)

FYI for vim users. If you are using a different language server plugin than vim-lsc you can set the _METALS_CLIENT variable yourself and use the metals-client script.

It's very odd that metals needs to know what client your using when the whole point of a language server is to be client agnostic.

amesgen commented on 2019-04-19 16:23 (UTC)

Perfect, thanks for the nice work on this package!

isomarcte commented on 2019-04-19 15:36 (UTC)

@amesgen, I definitely can. That's a great idea and I'm sorry I missed it.

The 0.5.0-6 build provides this now.

amesgen commented on 2019-04-18 23:57 (UTC)

Can you enforce Java 8 in the start scripts?

https://wiki.archlinux.org/index.php/Java#Launching_an_application_with_the_non-default_java_version