One thing I have been doing recently is setting up Artifactory on my local machine and caching the company / external repositories on that.
Even though the full artifactory has little to no performance impact on my machine I have often thought that a lighter weight version of Artifactory could be built into gradle deamon for rapid resolution of local and remote artifacts. Even better would be a distributed local repository that automatically sync'd with the company repository. -Mike On Fri, Mar 16, 2012 at 6:56 AM, Szczepan Faber <[email protected]> wrote: > On Thu, Mar 15, 2012 at 3:33 PM, Luke Daley <[email protected]> > wrote: >> >> Hiya, >> >> I'm working on remembering what the advertised last modified of an >> artifact was when we downloaded it. This allows us to avoid downloading >> changing artifacts if their TTL has expired, but they haven't changed at the >> source. >> >> I have this working for the target artifact (e.g. the jar), but not for >> the metadata (e.g. pom.xml, ivy.xml). So, do we want to avoid downloading >> unchanged metadata files? Metadata files are typically small so the gains >> won't be as significant as with artifacts, but I do think it's worth doing. > > > Me too. Network hit is still a hit. > >> >> >> The thing that's stopping this from working is that we don't push metadata >> to the ArtifactResolutionCache. >> >> As part of this work, I've changed the method that we use do this from: >> >> File storeArtifactFile(ModuleVersionRepository repository, >> ArtifactRevisionId artifact, File artifactFile); >> >> to: >> >> File storeArtifactFile(ModuleVersionRepository repository, >> ArtifactRevisionId artifact, File artifactFile, Date lastModified, String >> artifactUrl); >> >> Would we want to store metadata artifacts in the ArtifactResolutionCache? >> I can't seem to find where we do cache metadata in the codebase. >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
