I was playing around with integrating (an updated version of) a Maven-Proxy daemon with Gradle, so you'd just hit the one proxy from all your builds. This makes things a lot faster and enables off-line mode (only hit localhost most of the time), and is also be nicer to all the poor repositories that you're beating the crap out of every time you build.
The down side is that you lose the ability to limit what repositories you visit to check for artifacts: in terms of security/theory/whatever, all projects practically check the superset of all repositories that were used by build scripts. But the check is only made once an hour per non-snapshot artifact, so that's fine for performance. Unfortunately, I had some issues with the conversation between Maven-Proxy and Gradle, and then life got crazy with school, so I put it on the back burner. If you're interested in checking out that code, fork my Gradle-Plugins repo on GitHub. ~~ Robert. On 8 November 2010 16:18, Paul Speed <[email protected]> wrote: > > > On 11/8/2010 4:14 PM, Adam Murdoch wrote: > >> >> On 08/11/2010, at 5:12 PM, Paul Speed wrote: >> >> >>> >>> On 11/8/2010 1:10 AM, Adam Murdoch wrote: >>> >>>> >>>> There's a few things we'd like to change in Gradle to help deal with >>>> this problem: >>>> >>>> * Add some better diagnostics, so you can see which >>>> dependencies/repositories are taking the time. For example, dependency >>>> resolution might be integrated into the profiling report. >>>> >>>> * Provide a way to specify which repository (or repositories) to use for >>>> a given dependency. This would allow you to optimise how Gradle searches >>>> for your dependencies. >>>> >>>> * Deep integration with the dependency management. This would let you do >>>> things such as providing your own caching strategies. >>>> >>>> >>> Those would be nice. >>> >>> Maybe there's already a way to do this, but my personal wish would be >>> to be able to temporarily disable all remote access, like on the >>> command line or something. >>> >>> For example, sometimes my internet connection goes down and it kills >>> my build time-wise unless I go and manually comment out the >>> repositories. In this case, I already have all of the dependencies I >>> need, I just want to disable the rolling check for snapshots in remote >>> repositories. Sometimes it's just that one of the repos in my list >>> goes down and it would be nice to just ignore them all for a while. >>> >>> Is there maybe already a way to do this? >>> >> >> Not really. I've not tried this, but you should be able to set the >> snapshot timeout for each repository to 'never'. For example: >> >> import org.gradle.api.internal.artifacts.ivyservice.GradleIBiblioResolver >> >> if (project.hasProperty('offline') { >> repositories.withType(GradleIBiblioResolver).allObjects { repository -> >> repository.snapshotTimeout = GradleIBiblioResolver.NEVER >> } >> } >> >> This isn't really an 'offline' mode as such. It just reduces the >> likelihood that Gradle will try hit the network. >> >> Again, by providing deep integration with the dependency management >> system, you'll be able to easily add code which can short-circuit any or >> all of the repositories, and so implement an 'offline' mode. >> >> Perhaps better than a manual mode that you have to set, would be if >> Gradle could better detect and deal with unreachable repositories. For >> example: >> >> * Apply more sensible timeouts, rather than the TCP timeout. For >> example, when checking for an updated snapshot, wait maybe 15 seconds. >> Perhaps combine this with parallel resolution. >> > > This would be good... though without parallel resolution this would still > add a minute and a half or so to some of my builds when I'm "offline" for > some reason. > > > >> * Add something to the Gradle UIs which would let you skip dependency >> resolution when Gradle is just checking for updates. For example, you >> might be able to do ctrl-s, say, to skip resolution. >> >> * The Gradle daemon resolves dependencies in the background, so that >> when you execute a build, it already knows the status of each >> repository, and whether there are any updates. >> >> > Neither of those would help me personally, unfortunately. > > I've been meaning to look through things a bit deeper to understand why an > "offline" switch is hard/impossible... or what it would take to add one, > etc.. In the mean time, I may at least try the resolver trick above to see > if it improves things when I'm unplugged. > > > -Paul > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
