Andreas Axelsson wrote:
When I run ivy:retrieve, all dependencies that are copied to my lib folder
maintains the date of the file in the cache. That means when I change my
dependency to a version which has an older date, even if the revision is newer,
the file won't be copied to the lib folder, as the retrieve code looks more or
less like this:
foreach file in moduleFilesInCache {
if shouldCopy(file, target) copy(file, target);
}
bool shouldCopy(file, target) {
if !exists(targetFile) return true;
return target.date < file.date;
}
Basically, ivy:retrieve will never copy a file with an older date over a later
one, even if that's what you ask it to do.
The problem is only in the retrieve step, resolve actually resolves the correct
version and copies it to the cache.
However, when Ivy populates the cache, it keeps the timestamp of the original
file it downloads, at least for the FileSystemResolver. (We only use Ivy to
manage our internal modules at the moment.) I'm not sure if it's the publish
date or if it's the date when the file was originally built, but that makes
little difference in this case. The end result is that the only way to get an
older version copied to my lib folder is to clean it first.
IMHO, the behavior is kind of violating the principle of least surprise, when you're used to how most build tools and version control systems timestamp files on update. Compare it with your normal build rule of "build output if older than input" or when checking out an earlier version of a source repository.
Also, while going to a lower revision might be a situation that you can handle
manually, by cleaning, say that I'm upgrading to a higher revision that's been
built earlier than the current. It wouldn't be completely unlikely that the
patch revision (e.g. 1.0.2) of a module has been published later than the next
point release (e.g. 1.2.0).
<caches checkUpToDate="false"/> prevents the uptodate check during retrieve.
Tom
