Ethan Atkins 2b2b84f589 Use FileTreeDataView to collect files ... Now that we have the fileTreeView task, we can generalized the process of collecting files from the view (which may or may not actually cache the underlying file tree). I moved the implementation of collectFiles and addBaseSources into the new FileManagement object because Defaults is already too large of a file. When we query the view, we also need to register the directory we're listing because if the underlying view is a cache, we must call register before any entries will be available. Because FileTreeDataView doesn't have a register method, I implement registration with a simple implicit class that pattern matches on the underlying type and only calls register if it is actually a FileRepository. A side effect of this change is that the underlying files returned by collectFiles and appendBaseSources are StampedFile instances. This is so that in a subsequent commit, I can add a Zinc external hook that will read these stamps from the files in the source input array rather than compute the stamp on the fly. This leads to a substantial reduction in Zinc startup time for projects with many source files. The file filters also may be applied more quickly because the isDirectory property (which we check for all source files) is read from a cached value rather than requiring a stat. I had to update a few of the scripted tests to use the `1.2.0` FileTreeViewConfig because those tests would copy a file and then immediately re-compile. The latency of cache invalidation is O(1-10ms), but not instantaneous so it's necessary to either use a non-caching FileTreeView or add a sleep between updates and compilation. I chose the former.		2018-10-09 12:09:42 -07:00
..
src	Use FileTreeDataView to collect files	2018-10-09 12:09:42 -07:00
NOTICE	Add, configure & enforce file headers	2017-10-05 09:03:40 +01:00