Exactly. Plus some other issues we wanted to solve with the new cache format.
Apparently though, the old cache format had its charms as well :) Especially for users interested in poking around in the cache. Cheers! On Wed, Aug 3, 2011 at 8:28 AM, Johan Stuyts <[email protected]> wrote: > Hi, > > From my experience dependency managers, by default, use a shared cache for > all repositories. This results in cache contamination: projects which cannot > find a dependency using an empty cache are able to find a dependency because > it was downloaded for another project with different configured > repositories. So when someone adds a dependency which cannot be found in the > repositories configured for the project, but that can be found in the cache, > and checks it in, the build will break on machines where that dependency is > not already in the cache. > > In M3 this was also the case, but with M4 this has been resolved due to the > new cache structure. I was wondering if the prevention of cache > contamination was a requirement that resulted in the new cache structure, or > whether it was just a coincidental result and the new cache structure is > based on other requirements. > > If cache contamination prevention is by design, that would be great because > then I don't have to enforce a project-specific user home directory for each > project/branch in my build script wrapper. And it would prevent downloading > artifacts from repositories used by multiple projects multiple times. > > -- > Regards, Johan > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
