One task to build everything


(Greg Ward) #1

An ancient tradition with Make is to make your first target depend on everything, so simply running “make” builds everything. SCons does this even better: running “scons” means “build all targets under the current directory”. Works great, and you don’t need to follow ancient traditions; it just works.

Is there an equivalent with Gradle – e.g. a “build everything” task? Or would I have to define it myself and make it depend on everything?

Thanks –


(Luke Daley) #2

The conventional task for just creating everything that the build creates in Gradle is the ‘assemble’ task. For creating and testing, it’s ‘build’.

The ‘assemble’ task builds all of the publish artifacts that are part of the ‘archives’ configuration which is the default configuration for publications. The ‘build’ task depends on ‘assemble’ and ‘check’ (which runs tests/verifications).

So how to achieve this depends on what kind of build you have and what it creates.


(Greg Ward) #3

Nope: “gradle assemble” reports that it has nothing to do. Example:

$ hg purge --all
$ gradle assemble
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
  BUILD SUCCESSFUL
  Total time: 3.289 secs

If you’re not familiar with Mercurial, “hg purge --all” means “remove all files not tracked by Mercurial” – i.e. return my working directory to a pristine state, as though it were a fresh checkout. This guarantees there are no build products, or caches/databases maintained by build tools.

So it’s impossible that all my tasks are up-to-date.

I wonder if this is because I’m using sourceSets to specify various Java components; I simply don’t have a “main” component. Thus, “compileJava” and downstream tasks have nothing to do… but “compileCommonJava” and “compileCoredbJava” (two of my source sets) certainly have stuff to do.

Here’s a skeleton of my build.gradle:

apply plugin: 'java'
sourceSets {
      // Common libraries that would be useful for anyone writing Java
    // anywhere
    common {
        output.classesDir = file('.build/classes/common')
        java {
            srcDirs = [...],
            compileClasspath = files([...])
        }
    policy {
        output.classesDir = file('.build/classes/policy')
        java {
            srcDirs = [...]
        }
        compileClasspath = files([...])
    }
    [...other components...]
}

As a temporary hack, I’ve added an “all” target that forces compiling all my source sets:

task all {
    dependsOn commonClasses, policyClasses, coredbClasses
}

But surely there is a better way…?


(Greg Ward) #4

Oh yeah: aren’t tasks “assemble” and “build” added by the Java plugin? What if I’m using Gradle for a non-Java project? (Hypothetical example: I am building a Java project, but I’m curious.)


(Luke Daley) #5

Do you end up creating jars of these source sets?


(Luke Daley) #6

Then you’d use the ‘build«configuration»’ task rule as the start, and add your own ‘build’ task that did this likely by depending on one ore more ‘build«confguration»’ tasks.


(Greg Ward) #7

Currently: no, I haven’t bothered. Don’t really need jars, since I just need to ensure that the classes from component i-1 are in the compile-time classpath of component i. A classes/$name directory is just as good for that purpose as $name.jar.


(Luke Daley) #8

right, that’s the missing piece. You could just wire this in to build:

build {
  dependsOn { sourceSets*.output }
}