There was already a similar issue: http://issues.gradle.org/browse/GRADLE-1697 Still hoping to hear a fix will be forthcoming, and that the next rc/milestone will be back on par with m3 (or preferable faster).
A little surprised that so few have complained about the rather dramatic performance degredation. Cheers Magnus > From: [email protected] > Date: Thu, 4 Aug 2011 09:37:04 +1000 > To: [email protected] > Subject: Re: [gradle-user] Why is gradle hitting remote repositories for > every build even after caching > > > On 04/08/2011, at 6:57 AM, Doug Lethin wrote: > > > Perhaps I'm just misunderstanding things, as I'm relatively new to Gradle > > (rapidly becoming a big fan..), but I'm running into a curious problem that > > I was hoping someone might be able to set me straight on. > > > > It seem to be related to milestone4, as I don't get the same behavior in > > milestone-3. > > > > I have a build with *A LOT* of dependencies -- directly and transitively. > > What I'm discovering is that each time I perform a build, for each > > dependency, gradle is performing 3 requests: > > > > - HTTP HEAD for the pom file > > - HTTP GET for the pom.sha1 checksum file > > - HTTP GET for the pom.md5 checksum file. > > > > And occasionally it will redownload the jar files themselves, even though > > nothing has changed. (These are not snapshot versions, but harcoded fixed > > version numbers) > > > > It does this every time a build is performed. The the behavior I would > > expect is that once a fixed version is downloaded from a repository, there > > is no need to communicate to that repository in regards to that resource. > > > > This is easily reproducible performing the 'gradle dependencies' command. > > > > For one of my projects in a multi-project build it it taking 1min49 seconds > > just to list the dependencies using milestone-4 vs only 13 seconds with > > milestone-3. > > > > Is this a bug in the new Wharf repository resolver, or am I missing > > something obvious? > > It's definitely a bug. > > Can you please raise an issue so it gets addressed in the next release. > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > >
