Apologies for sounding rather demanding/impatient in my previous posting. I really believe in gradle and have come to really enjoy using it. I would go as far as counting myself a gradle fan. Actively trying to convince people to use it and recommending clients to adopt it. I'm obviously not a committer, but hopefully i might be able to contribute little bits and pieces codewise in the not to distant future.
When I first evaluated gradle, build performance was a big issue for the company I was consulting for. I still believe its very important for any newcomers when first trying out gradle (gradle daemon and incremental builds aside). This also applies for all those smaller projects where you expect rapid turnarounds for your builds. Im guessing the performance issues here are related to the major rewrite of the underlying cache solution, and its obviously understandable that there will be issues with such an undertaking. I understand there are a lots of cool and important things which are in the pipeline for gradle. I guess I just want to emphasize the performance aspect and to raise a tiny flag of warning about the potential of "bad press" if a release suddenly has a significant degredation. Cheers Magnus From: [email protected] To: [email protected] Date: Thu, 4 Aug 2011 01:56:36 +0000 Subject: RE: [gradle-user] Why is gradle hitting remote repositories for every build even after caching 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 > >
