sbt-assembly VS sbt-revolver

sbt-assembly is still my go-to. So what I'd prefer is the combination of sbt-assembly (to build my .jar that I can just java -jar anytime I want) and sbt-jib (to construct my OCI image including my assembly .jar for deployment in some container orchestration environment).

You may also use sbt-assembly to produce an uber JAR that embeds the Scala stdlib together with your code, which means that now for running your program you only need a JRE like java -jar app-assembly.jar. This option is great because now if you start adding dependencies to your project those are also included in this massive JAR.

Sbt-assembly defaults to silently concatenating configs. But even if it didn't, the configs wouldn't be in any particular order when resolving.

Ticket of record is https://github.com/sbt/sbt-assembly/issues/391

With the sbt-assembly plugin you can create JAR-files with all of its dependencies (fat JARs). sbt assembly creates this target/scala-2.12/apply-at-vdb-assembly-0.1.0-SNAPSHOT.jar which has a size of around 42MB:

Another thing to look into is sbt-revolver, this will shorten the turnaround time on whatever machine is running sbt. I remember it being pretty helpful when I was working with scala.js. Good luck!

SBT. It's not because of the pseudo-scala config language, that looks especially alien next to braceless Scala 3 code. Or the weird symbolic operators. The big problem is correctness; in almost every project I've had to use spray-resolver because I've encountered weird bugs because SBT reuses the same dirty JVM. I really thing Drip would help here. I'll keep using SBT because it has the best Scala ecosystem support and great plugins like sbt-crossproject. It would also be great to be able to write build.sbt files in modern, regular Scala.