[GRADLE-2397] When a task is declared with `overwrite: true`, task dependencies on original task stay intact Created: 21/Jul/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 1


 Description   

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

 Comments   
Comment by Gradle Forums [ 21/Jul/12 ]

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.
Comment by Gradle Forums [ 21/Jul/12 ]

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

Comment by Gradle Forums [ 21/Jul/12 ]

`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.

Comment by Gradle Forums [ 21/Jul/12 ]

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.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:20:49 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.