There are just too many instances in which sbt's code relies on
the `lastModified`/`setLastModified` semantics, so instead of moving
to `get`/`setModifiedTime`, we use new IO calls that offer the new
timestamp precision, but retain the old semantics.
FileInfo is used to wrap information like last modified time on
files that may or may not exist. Arguably, that does not make
much sense: the non-existent files should not lead to modification
file information, hashes, and a persistent serialized version of
the resulting meaningless information. However, considering that
the FileInfo information is serialized and saved, it is necessary
to preserve compatibility at this stage. Therefore the modification
time is explicitly set to zero for those files that do not exist
when each FileInfo is built.
The input validation for caching currently relies on having a stack of `scala.math.Equiv`, which is questionable since it can fallback to universal equality.
This is likely related to the intermittent caching behavior we are seeing in https://github.com/sbt/sbt/issues/3226
Looks like the reason that util-cache depended on util-collection was to
define the sjson-new formats (HListFormats) for util-collection's HList.
Given that util-collection already depends on sjsonnew, HListFormats can
also be defined in util-collection.
All that was left then was (a) HListFormatSpec requires
sjsonnewScalaJson, so that was added in test scope, and (b) HListFormats
had to be dropped from sbt.util.CacheImplicits - HListFormats will have
to be imported and/or mixed-in where required downstream. For importing
convenience I defined a companion object.
sbt/util#45 implemented caching using sjson-new. Now many of the functions take `CacheStore` that abstracts the caching ability.
sbt/sbt#3109 demonstrates that setting up CacheStore requires boilerplate involving concepts introduced in sbt 1.
This change adds back overrides using File by making assumption that majority of the time we would want standard JSON converter.