Is gradle's local cache tied to gradle version?


(Doug Lethin) #1

I saw some of the changes listed in 1.0-milestone.6-SNAPSHOT that I wanted to try out so I switched over to using it.

To my surprise, it forced me to re-download ALL of my dependencies again, even though I had downloaded them previous builds using 1.0-milestone-5. Is this intended behavior?

Looking at my ~/.gradle file, I see that I had an ~/.gradle/caches/artifacts-3 directory, and now I have in addition an artifacts-4 directory with duplicate entries for my dependencies.

I know that these are SNAPSHOTs and anything can change prior to 1.0, but I assume the intent is that the local cache will become stable and sacrosanct (wow, never used that word in a sentence before…) such that upgrades in gradle version will respect what’s in the cache from previous versions so as not to redownload everything?

Thanks.

Doug


(Luke Daley) #2

It’s not tied to the Gradle version, but to the particular cache layout that Gradle uses for that particular version. So as we need to change the cache structure we increment it (e.g. artifacts-5 next time it changes).

We are discussing ways to copy things over from the previous cache where appropriate. Some kind of mechanism will be in place before 1.0.


#3

We are also working on separating the meta-data cache from the artifact cache. A lot of the dependency resolution optimisations we’re working on require changes to the meta-data cache format, but not the artifact cache. Since the meta-data is generated from downloaded artifacts (eg .pom files), you shouldn’t need to download anything to regenerate it. (Unfortunately, even this cache separation will be a version change, so expect to download everything again when we make this change!).

In truth, with our cache we are currently focussing more on “make it better” and less on “make it backward compatible”. This is a deliberate choice; we effectively publish a new snapshot every day and it would be a nightmare to try to maintain perfect compatibility between all of the possible versions out there in the wild.

As we approach Gradle 1.0 our cache format will stabilise and post 1.0 our goal will be to make further upgrades seamless and painless.