On 24 January 2012 02:16, Hans Dockter <[email protected]> wrote:
> 1.) When we refresh the cache, do we plan also to consider the SHA1 values > of the metadata files in the future? Right now we always download the > metadata when we do a refresh. Not that I think this is a big issue. Just > curious to understand the background and plans on this. > We already do consider the SHA1 value of metadata files as well as artifact files. But I think I found the bug that makes it look like it's not working. Our SHA1->String conversion is omitting any leading zero, so we are truncating it to 39 characters in these cases. This means that in certain cases our calculated SHA1 string does not match the published SHA1 string, which has 40 characters. 2.) The following looks like a bug to me. If you have a look at the > cache-expiration example at: > https://github.com/gradleware/live-demos/tree/master/cache-expiration > - Publish the artifacts and call show on the consumer. > - Publish again and call consumer:show with --refresh dependencies. Zoo is > downloaded again (no sha1 file available). Moo is not downloaded again. It > has a sha1 file but the sha1 file has changed. The moo metadata is > downloaded again as part of the refresh. > I think you're seeing the effect of the new artifacts being published to your local maven cache as part of the uploadArchives task. Here's what I get with "gradle -g home -i --refresh dependencies show" with clean home and m2 repository: Resource found. [HTTP GET: http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar ] downloading Http GET Resource: http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar... Download http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar [SUCCESSFUL ] org.cachepolicy.moo#moo;1.0!moo.jar (15ms) /Users/daz/dev/gradlex/live-demos/cache-expiration/consumer/home/caches/artifacts-8/filestore/org.cachepolicy.moo/moo/1.0/jar/b3f20ce70cb5aa2134dd66a5ec8519079b3a6de7/moo-1.0.jar And here's what I get when I run that command again after publishing again Checksum SHA-1 matched cached resource: [HTTP GET: http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar.sha1 ] downloading CachedResource: /Users/daz/.m2/repository/org/cachepolicy/moo/moo/1.0/moo-1.0.jar for http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar... [SUCCESSFUL ] org.cachepolicy.moo#moo;1.0!moo.jar (22ms) /Users/daz/dev/gradlex/live-demos/cache-expiration/consumer/home/caches/artifacts-8/filestore/org.cachepolicy.moo/moo/1.0/jar/dd5a542e2348ff3b75f908db1dca49d1d027b863/moo-1.0.jar You'll notice that the CachedResource in the second run is actually coming from .m2/repository. So if you run without '-i', you won't see any "download" messages. If I try again but delete .m2/repository before the second run I get: Checksum SHA-1 did not match cached resources: [HTTP GET: http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar.sha1 ] Resource found. [HTTP GET: http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar ] downloading Http GET Resource: http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar... Download http://192.168.123.159/~daz/mavenrepo/org/cachepolicy/moo/moo/1.0/moo-1.0.jar [SUCCESSFUL ] org.cachepolicy.moo#moo;1.0!moo.jar (18ms) /Users/daz/dev/gradlex/live-demos/cache-expiration/consumer/home/caches/artifacts-8/filestore/org.cachepolicy.moo/moo/1.0/jar/dbfc1c7de3b13590392ba4f11687db77b8f05957/moo-1.0.jar The last run is what you'll see if the publisher was run on a different box to the consumer. Make sense? -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
