Jar task creates 'build' dir even when not executed

In my build file I have the following snippet:

subprojects {
      onlyIf {

(and I have to say, that is one beautiful DSL…onlyIf { compileJava.didWork }. Wow. Gradle team, I lift my hat in admiration)

however, even in the projects (this is a multi project build) where the jar task is “SKIPPED”, the “build” directory is still created. Digging into the jar task source we find the following:

//Jar.groovy in gradle source
public class Jar extends Zip {
    Jar() {
        extension = DEFAULT_EXTENSION
        manifest = new DefaultManifest(project.fileResolver)
        // Add these as separate specs, so they are not affected by the changes to the main spec
        metaInf = copyAction.rootSpec.addFirst().into('META-INF')
        metaInf.addChild().from {
            MapFileTree manifestSource = new MapFileTree(temporaryDir)
            manifestSource.add('MANIFEST.MF') {OutputStream outstr ->
                Manifest manifest = getManifest() ?: new DefaultManifest(null)
                manifest.writeTo(new OutputStreamWriter(outstr))
            return new FileTreeAdapter(manifestSource)
        copyAction.mainSpec.eachFile { FileCopyDetails details ->
            if (details.path.equalsIgnoreCase('META-INF/MANIFEST.MF')) {

Note the use of mysterious variable ‘temporaryDir’? Well he comes from the following snippet in AbstractTask.java a bunch of inheritance levels up the chain:

//AbstractTask.java in gradle source
    public File getTemporaryDir() {
        File dir = getServices().get(TemporaryFileProvider.class).newTemporaryFile(getName());
        return dir;

So to summarize: just by creating the ‘Jar’ task, we access the ‘temporaryDir’ property which in turn creates the directory “build/tmp” under the executing project dir.

Wouldn’t it be nice if we were a tad more lazy about this evaluation? I have a large multi-project build where I would like to leave the 50 sub projects which do not have any sources or resources untouched which is why I added the onlyIf clause.

Right now we get “build/tmp” directories in them even when we prevent the jar task from executing and as far as I can see there is no way to apply either the groovy or java plugins without getting a ‘build/tmp’ directory however much we prevent the tasks from running for that specific subproject.

Any help much appreciated. If I don’t hear back from anybody on a way to work around this within a few days, I’ll open a JIRA and close this thread.

(For reference: this is using 1.0-milestone-3)

Here is a corollary to the above - if you create an empty directory with the following build.gradle in it:

apply plugin: 'java'

and execute the following gradle command:

$ gradle tasks

the directory structure will look as follows after (assuming the directory you are running from is called ‘bar’):

$ tree
├── build
│   └── tmp
   └── bar
└── build.gradle

this is to me quite unintuitive. No tasks were executed and still a build directory is created.

I have created the following JIRA on this:


Still an issue in M6.

I’ve fixed this for m7. Thanks for investigating the cause. It made fixing it a lot quicker.

Happy to be of service! And thank you for the fix!

Do you guys have any feeling for a time frame for m7? Won’t hold you to it, just trying to get a feeling for if it will be in weeks or in months. Also is there some place where we can see what m7 will include? I know about the development roadmap, but it doesn’t really tell you anything about milestones. Perhaps “this week in gradle” could give us a list?

As a side note, running a google search on “gradle roadmap” gets you to a quite outdated codehaus page. I took the liberty of adding a note with a link to the current roadmap to the top of that page, it hasn’t shown up yet in the rendered version but is visible via the ‘view’ link on that page. Not sure what the deal is, probably a delay in confluence theme rendering or some such arcanea.

m7 is definitely weeks away and not months.

This wiki page is the place to go for the time being. We update the release notes as we go.

Thanks for the heads up on the roadmap thing. We’ll get gradle.codehaus.org shutdown.