| 25 Sep 2022 |
|  Olli joined the room. | 11:34:38 |
| Olli | Metals spawns a sbt server, right? When I run sbt myself I get
[warn] sbt server could not start because there's another instance of sbt running on this build.
Is there a way to use the existing server? | 11:34:43 |
 armanbilge#6192 | yes | 11:34:43 |
| armanbilge#6192 | you have two options: use the metals sbt server, or have metals use your sbt server | 11:34:44 |
| armanbilge#6192 | if you want to use the metals sbt server, shutdown your server and instead use sbt --client | 11:34:44 |
| armanbilge#6192 | if you want metals to use your sbt server, then do sbt --client and then shutdown | 11:34:44 |
| armanbilge#6192 | this will kill the metals server and it will connect to yours | 11:34:44 |
| armanbilge#6192 | personally I prefer to force metals to use my server | 11:34:44 |
| armanbilge#6192 | * if you want to use the metals sbt server, shutdown your sbt and instead use sbt --client | 11:35:52 |
| Olli | Thanks! | 11:36:07 |
| Olli | Second question: is there a way to find out what sbt is currently running? | 11:36:34 |
| armanbilge#6192 | wdym? | 11:36:44 |
| Olli | I've had it happen a couple of times that when I try to run my server the port is already bound by something | 11:37:22 |
| armanbilge#6192 | if you found out what sbt is currently running, what would you do with that information? | 11:37:52 |
| Olli | Tell it to stop 😃 | 11:38:09 |
| armanbilge#6192 | sbt --client then shutdown 🙂 | 11:38:16 |
| Olli | Right | 11:38:30 |
| Olli | Thanks! | 11:38:32 |
| armanbilge#6192 | 🙂 | 11:38:33 |
| Olli | Is sbt-native-packager the preferred way to create docker images from sbt? | 11:38:57 |
 BalmungSan#5059 | AFAIK yes.
Although, for simple projects I have been fine using sbt-assembly and a simple Dockerfile
However, I have been wanting to give sbt-native-packager a try. | 14:04:17 |
 velvetbaldmime#6377 | sbt-native-packager is the way, yes
it lays out dependency jars separately from the main app jar, which is the thing you want for lazy loaded classes | 14:05:42 |
| velvetbaldmime#6377 | it's also super easy to use, so why not. | 14:05:52 |
| Olli | Yeah makes sense! | 19:15:30 |
 sideeffffect#8379 | Hello everybody. I have a question about cross compilation with sbt.
I have a project which is crosscompiled to multiple Scala versions and multiple platforms.
When I run sbt '++ 2.11.12' -v Test/compile, sbt tries to compile certain projects for 2.13.8 🙀 Specifically those that have scalaVersion := "2.13.8" or crossScalaVersions -= "2.11.12".
Even though the documentation says that
When a [command] is passed in to ++, it will execute the command on the subprojects that supports the given <version>.
https://www.scala-sbt.org/1.x/docs/Cross-Build.html
I don't even see any
[info] Setting Scala version to 2.11.12 on 25 projects.
[info] Switching Scala version on:
...
[info] Excluding projects:
or anything like that, which is a bit worrying.
What am I doing wrong? Thanks for any help, hint or pointers 🙏 | 21:55:11 |
| armanbilge#6192 | you are not doing anything wrong | 21:55:54 |
| armanbilge#6192 | that's just sbt | 21:55:58 |
| sideeffffect#8379 | Well... but isn't the behavior in direct contradiction with the documentation and the intent of the ++ feature? Shouldn't we file a bug for this? | 21:59:45 |
| sideeffffect#8379 | You might want to give https://github.com/schmitch/sbt-jib a try 😉 | 22:02:01 |
| sideeffffect#8379 | * You might want to give https://github.com/schmitch/sbt-jib a try 😉
It makes the container image layers in a way that caching works well (unlike sbt-native-packager) | 22:05:12 |
