dependsOn behaviour has changed since Gradle 1.0-milestone-3: How to achieve required result now?

Old Forum
1

Previously I was using Gradle 1.0-milestone-3.

Upgraded for another unrelated reason to the current, Gradle 1.0 (as of 19th Jul 2012).

Now the build is broken, as the tasks I used to be able to insert into the correct position of the build, no longer get run.

That is, the ‘dependsOn’ doesn’t work as it used to.

What I used to achieve, is insert a task that was always run directly after the ‘classes’ task of the java build. This was done, by suggestion from someone on a gradle forum (in earlier days), like this:

task obfuscate(dependsOn: classes) << {
   // the body of the task
}

The problem is demonstrated by the following script. I have also inserted here below the output from the build script, as run by both versions. Note the difference in the latest version (the obfuscate task is never run).

How can I get back my obfuscate task? Was it wrong to do it like this previously? Is it a bug?

thanks in advance for any ideas/help.

sean

apply plugin: 'java'
    def buildTime = new java.util.Date()
  dependencies {
 }
  sourceSets {
    main {
        java {
            srcDir 'src'
        }
        resources {
            srcDir 'src'
        }
    }
      test {
        java {
            srcDir 'test'
        }
        resources {
            srcDir 'test'
        }
    }
}
    task obfuscate(dependsOn: classes) << {
 println "in obfuscate"
}
  task jar(dependsOn: obfuscate, type: Jar, overwrite: true){ // we provide our own main jar task
    manifest.from("src/META-INF/MANIFEST.MF")
 // because our main jar should be obfuscated
    manifest.attributes 'Build-Time': buildTime.toString()
    from project.sourceSets.main.resources
    from "$buildDir/obfuscated-classes-extra"
}
  task unobfuscatedJar(dependsOn: classes, type: Jar) { // we also provide an extra jar task, to provide our unobfuscated jar
       baseName = "${project.name}-unobfuscated"
       manifest.from("src/META-INF/MANIFEST.MF")
       manifest.attributes 'Build-Time': buildTime.toString()
       from "$buildDir/classes/main"
}

the output

------------------------------------------------------------
Gradle 1.0-milestone-3
------------------------------------------------------------
  Gradle build time: Monday, 25 April 2011 5:40:11 PM EST
Groovy: 1.7.10
Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Ivy: 2.2.0
JVM: 1.6.0_24 (Sun Microsystems Inc. 19.1-b02)
OS: Linux 3.2.0-26-generic-pae i386
  sean@svUbuntu10:~/dev/test$ gradle build
:compileJava UP-TO-DATE
:processResources
:classes
:obfuscate
in obfuscate
:jar
:unobfuscatedJar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check
:build
  BUILD SUCCESSFUL
  Total time: 4.526 secs
        =============================================
  sean@svUbuntu10:~/dev/test$ /mnt/data/bin/gradle-1.0/bin/gradle build
:compileJava
:processResources
:classes
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test
:check
:build
  BUILD SUCCESSFUL
  Total time: 6.618 secs
2

Looks like a problem with ‘overwrite’, namely that task dependencies on the original task don’t get updated and still refer to the original task. I’m not exactly sure what the expected behavior is, but the current behavior looks wrong to me. Two potential solutions:

  • Reconfigure the ‘jar’ task rather than overwriting it * Update dependencies on ‘jar’ explicitly, after you have overwritten it. For example: ‘assemble.dependsOn = [jar]’. This might get hairy though.
3

Hi Peter, and thanks for your quick reply!

Are you saying that a ‘reconfigure’ would always be the better (and less likely to regress) option for this kind of requirement? Or, would have been the overwrite just as valid and (based on this, and your opinion that the “current behaviour looks wrong to me”), my problem will be fixed by a bug-fix in upcoming versions of gradle?

We have already many in use gradle scripts, which are stored in our SCM system (tags/branches) and built automatically from those gradle files exported from svn. It would be a lot of work to update the scripts to work around a bug that will be fixed in future versions. But if you were to say, that the reconfigure would have been the better or more correct way to go about it, then It could be justified (some time in the future).

thanks and regards,

sean

4

‘overwrite: true’ always feels like a workaround to me, and I try to avoid it whenever I can. I definitely prefer reconfiguration. Whether the current behavior is a bug will require some discussion. If it is deemed a bug, it will likely be fixed. By the way, a third solution might be to obfuscate the classes in place. Then you wouldn’t need to change anything about the ‘jar’ task. Still, reconfiguring the task seems like the best option to me.

5

Hi,

Ok, thanks for the advice. I will in future stick to reconfiguration.

However, I would also think that, either, ‘overwrite: true’ should be deprecated (being a bit of a hack) , or the old (and I think, expected) behaviour fixed.

FYI, I just downloaded all the releases since milestone-3.

in milestone-4, my overriding tasks dependency gets done,

and in milestone-5 it does not. So the regression occurred first in milestone-5.