Excessive artifact download when using SFTP resolver

(Adrian Abraham) #1

I’m currently using an Ivy repository accessed via SFTP. I haven’t been able to figure out how to use the ivy { } block with SFTP, so I’m doing (roughly) the following:

repositories {
 def repo = new org.apache.ivy.plugins.resolver.SFTPResolver()
 configure(repo) {

When I try to run my build with M7, I see it redownloading all the jars, but I don’t see it trying to download .sha1 or .md5 files. All the artifacts are already present in artifacts-4.

Does duplicate artifact detection only work inside an ivy{} block? Is there something else I need to do to get Gradle to reuse what it already has?


No, re-using cached artifacts based on SHA1 keys does not work when you use an ivy resolver directly. This behaviour is only available for repositories declared as ivy{}, maven{} and mavenRepo().

Soon we will be working on extending the flexibility and use cases supported by these repository declarations. However, SFTP transport is not currently on the roadmap, and is not likely to be implemented before 1.0 (unless we receive a user contribution!).

I’ve added this to our issue tracker as GRADLE-2070. You can vote for the issue there.

(Adam Murdoch) #3

@Daz, it might not be a bad option to shuffle things around so that the reuse stuff is a decoration that works with any Ivy ‘RepositoryResolver’, rather than being baked into ‘HttpResourceCollection’.


I think that might be tricky… We had to change the RepositoryResolver implementation significantly in order to make the ArtifactId available when getting a resource.

Maybe more practical would be to make it easy to use an existing ivy Repository implementation to create a Gradle ArtifactRepository. For starters we could use our ResourceCollectionResolver to do this (with a few modifications so that artifact-reuse is a decorator on a ResourceCollection).

I guess we could then the check for a known RepositoryResolver implementation, extract the underlying Repository and wrap it in our own ResourceCollectionResolver implementation. Or we could just bite the bullet and implement handling of ssh and sftp urls ourselves, using the ivy repository implementations internally. Implementation would be straightforward; most of the work would be in testing…