Reason: The tracking file manager typically in large m2e projects will be used hundreds of times (due to hundreds of artifacts). If the projects are refreshed the files are re-read again and again. This could amount to as much as 43% of time spent in m2e MavenBuilder (in my scenario on Windows platform)
Changes: This commit introduces the read cache for tracking files assuming that those files do not change frequently (or at all). The cache entries are verified once per minute if the underlying file had changed its lastModified timestamp and if so they are re-read. If the file timestamp had not changed the entry is valid for one more minute. Additionally since on Windows canonicalization is expensive operation it is also being cached. Cached properties are defensively copied when returned. TODOs: - the cache is unbounded and there is no clearing policy based on LRU and maximum size (for instance). However for typical usages this will not be a problem since number of artifacts is probably couple of thousands and should not pose a problem for memory. I'm making this PR without much hope of approving it - this may not be something that is perceived as problematic by maintainers of this library, but I've stumbled on this issue while profiling m2e builds which are taking quite long (and I've decided to do something about it). [ Full content available at: https://github.com/apache/maven-resolver/pull/22 ] This message was relayed via gitbox.apache.org for [email protected]
