Documentation: neat trick using assemblyPackageDependency

[JoshRosen]

I learned about a neat trick in sbt-assembly which allows you to build separate JARs for your application's code and its dependencies: https://github.com/sbt/sbt-assembly#splitting-your-project-and-deps-jars

For example, if my build.sbt file contains

assemblyOption in assembly := 
  (assemblyOption in assembly).value.copy(includeScala = false, includeDependency = false)

dbcClasspath := Seq(assembly.value, assemblyPackageDependency.value)

then running dbcDeploy will upload two separate JARs (myproject-assembly-0.0.1-SNAPSHOT.jar and myproject-assembly-0.0.1-SNAPSHOT-deps.jar).

In principle, this might allow us to reduce the turnaround time when pushing a new version of a library from a slow connection (since we could skip re-upload of JARs whose SHAs are the same (not sure if we actually do this)). Even if we supported skipping re-upload of JARs that didn't change, that technique won't help users of the assembly unless they do the trick specified here, which is where I think this adds value.

Just wanted to write down this idea here so I don't forget about it.

[JoshRosen]

Actually, one trick that might be helpful is to define separate SBT tasks for deploying the dependency and user code assemblies; although this would be somewhat more manual than figuring out what changed automatically, it should be easily doable and would greatly improve development turnaround times for me.

[ssemichev]

+1
It will be very useful!