Faster Builds please

Old Forum Archive
1

Ok, i know using the GPars 1.0.0 lib, we can speed up groovy,etc if we know what we’re doing. My life is getting shorter by the minute waiting for my aging apple iMac to do big gradle 1.7-rc-1 builds. A 10% savings on elapsed time, doesn’t sound like much, but it still means a lot to many of us. So i can do my own dependency graph for a few tasks i KNOW can run together without conflicts. so something like:

build.script{
    compile "org.codehaus.gpars:gpars:1.0.0"
}
task doItFaster(dependsOn: [jar]) <<
{
 withPool {
  groovydoc().asynch(),
  javadocs().asynch(),
   template().asynch(),
  javadocJar().asynch(),
  copyImages().asynch()
 }
}

would sure save a little of my hair from being pulled out while waiting. Problem is: i dunno how

update ...

brain is still in gear - so if one of my tasks is already gonna be run as part of

gradle clean build

how can i prevent double execution of that task, once by my task and once as part ‘build’ ?

2

Helllo, In a multiproject build, you can already build different projects in parallel using the incubating --parallel flag. There are more plans to parallize task execution in gradle. But we definitely don’t want the build script author to bother with this explicitly. Instead gradle should figure what tasks can be executed in parallel .

cheers, rené

3

oui, that would be lovely - not to need to worry about which bits of the build script can be run together - by default. would this mean we could use the --parallel flag to run several sub-projects:

makejars.gradle, gendocs.gradle, deploy.gradle for the same source sets ?

4

Rene, are there are plans to improve dependency resolve in parallel builds, i.e. preventing duplicate downloads of artifacts?

5

do you see duplicate downloads of artifacts in your build? this was a known issue in earlier versions of gradle but should be fixed since 1.2 or so (or maybe 1.3).