Ability to prevent Caching? about sbt-assembly

[eed3si9n]

The generated cache grows to a total of 2GB!

As noted in #66, I think the problem is tempDir not getting cleaned up afterwards.

[hrjet]

Well to clarify, the size is not a problem by itself. (I have ample free space on the file system).
But the disk I/O slows down the build to a crawl (compared to what it could be).
Hence cleaning up will not solve the speed problem (on the other hand might exacerbate it).

One possible solution: Would it be feasible to expand jars in memory? I think this might also enable sharing jars across projects without complicating it too much.

[eed3si9n]

Hence cleaning up will not solve the speed problem

I'm closing this case then.

Would it be feasible to expand jars in memory?

Given that the user could have hundreds of library jars, I can't reliably assume that there's enough memory allocated to sbt.

[hrjet]

I would suggest not closing these issues too soon. Perhaps in future, we or someone else might get better ideas.

Given that the user could have hundreds of library jars, I can't reliably assume that there's enough memory allocated to sbt.

What if there was a setting to switch between on-disk-expansion v/s in-memory expansion? And the default would be on-disk-expansion.

[eed3si9n]

I'd like to use issues for actionable items and clearly defined defects or feature requests.

This case was opened asking about caching. Since it's looking like it's more of a performance issue, which is not a caching issue, I thought the case has done its job.

I'd be happy to review pull req that toggles in-memory expansion, or maybe you could start a discussion on sbt mailing list to get more ideas from others.