ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Xue <phil....@orionhealth.com>
Subject Ivy resolve getting staled descriptor after Ivy publish
Date Thu, 21 Jun 2012 06:27:21 GMT
Hi,

This is an issue that has been bothering us for quite some time. The issue was identified
in ivy-2.0.0 but we can also reproduce it on ivy-2.2.0

We have an Ant task that publishes the beta revision of our module to repository then resolves
and retrieves the newly published module.

Whenever we change the dependency in our beta revision (i.e. modify module descriptor ivy.xml)
the resolve that runs after publish would not pick up the newly published descriptor from
repository, instead it uses the local cached version which has staled dependency. This only
happens when both publish and resolve are running in the same Ant process, if they were executed
in 2 separate commands resolve works correctly

We believe what supposed to happen after publish is that local ivy cache should be out of
date (i.e. a new beta has just been published to repository) so the subsequent resolve should
have this logged in verbose mode:
"[ivy:resolve]     default-cache: revision in cache is not up to date: application#HelloWorld;6.12.0.beta"
this should be followed by a download of descriptor file from repository to update the local
cache, so that the resolve after publish would get the latest beta which has just been published.

However what happened to us is that when pulish and resolve were executed one after the other
in the same process, Ivy somehow thinks the local cache is up to date, this behavior is proven
by this entry in log:
"[ivy:resolve]     default-cache: revision in cache (not updated): application#HelloWorld;6.12.0.beta"
so instead of get it from the respository Ivy uses the local cache which is in fact not up
to date.

In our attempt to identify the issue, we have found the following code in DefaultRepositoryCacheManager

if (!rmr.getDescriptor().isDefault() && repLastModified <= cacheLastModified) {
    Message.verbose("\t" + getName() + ": revision in cache (not updated): " + mrid);
    rmr.getReport().setSearched(true);
    return rmr;
} else {
    Message.verbose("\t" + getName() + ": revision in cache is not up to date: " + mrid);
    if (isChanging(dd, mrid, options)) {
        // ivy file has been updated, we should see if it has a new publication
        // date to see if a new download is required (in case the dependency is
        // a changing one)
        cachedPublicationDate = rmr.getDescriptor().getResolvedPublicationDate();
    }
}

We are using URL resolver and our local cache is on file system, so I'd imagine "repLastModified
<= cacheLastModified" is checking the last modified date of local cache file against lastModified
HTTP header from the response of a repository descriptor request. We have confirmed that lastModified
HTTP header (repLastModified) is always greater than our local cache file's last modified
value (cacheLastModified) during resolve (i.e. publish runs before subsequent resolve, so
descriptor should always have a greater last modified on repository, theoretically we should
have never seen "revision in cache (not updated)" but this is what currently happening to
us.

Any subsequent ivy:resolve will put the local cache back in sync with repository and resolves
correctly if it were executed in a separate command.


In addition to that, we have also confirmed that:
1. "checkmodified" is set to true on resolvers in our ivy setting file
2. "changing" is set to true on ivy:resolve
3. System time on our build server (where Ant tasks are executed) is in sync with Ivy repository
server


Has anyone come across something similar before?

Thanks

Phil

Mime
View raw message