caching (sbt assembly touches target jar file even when source code doesn't change)

[teichert]

I want to use sbt assembly in conjunction with a bigger build process that is managed by make so it would nice if the timestamp on the jar that sbt-assembly produces would only change when necessary.

[eed3si9n]

You want sbt-assembly to produce a file only when it hasn't changed since the last time it built it?
Given that it incorporates dependencies from jar etc, relying only on timestamp seems like asking for trouble. I can imagine many of the build users making the exact opposite request that assembly should keep it simple, and always build everything from scratch when the user types "assembly".

Rather than embedding this logic into sbt-assembly, I think this is something that should be solved at sbt level perhaps reusing the logic from trigged execution. /cc @harrah

[harrah]

@eed3si9n I think it is reasonable for assembly to only rebuild the assembly if any of the timestamps of the inputs have changed. This is what sbt does for making jars, for example. See FileFunction for caching basic Set[File] => Set[File] functions, for example. There isn't a good built-in caching API because I haven't come up with one I like. You can see what is used for packaging, though.

[eed3si9n]

@harrah Is caching done in-memory or using files? In other words, would package/assembly across multiple runs of sbt still be cached?

[harrah]

@eed3si9n files. The cache information is stored in a file. You could imagine a special task (similar to streams) being available to give every task its own unique cache file, but you have to manually construct it right now.

[eed3si9n]

released 0.8.5 with this feature.

[teichert]

Awesome!

Thanks,

--Adam

[eed3si9n]

caching is optional for 0.8.6:

assemblyCacheOutput in assembly := true