On 20/04/2011, at 1:43 AM, Steve Appling wrote: > One of our tasks no longer works with milestone 2. Is anyone aware of an > intentional change that would have broken this, or is this a bug.
It was an intentional change, which I forgot to add to the breaking changes page. I've added it now: http://wiki.gradle.org/display/GRADLE/Gradle+1.0-milestone-2+Breaking+Changes#Gradle1.0-milestone-2BreakingChanges-Skippingtaskswithnosourcefiles Previously, the check whether to skip a task with no source files (ie checking those properties marked @SkipWhenEmpty) used to be implemented as a task action. This meant you could specify values for these properties in a doFirst { } closure. Now, the check is done earlier, before any of the actions of the task are executed. The main reason for this change was to move the empty-source check before the up-to-date check, so we can avoid paying the price for the up-to-date check if the task is not actually going to execute. For example, we don't need to scan the output directory for a processResources task when there are no resources. Or resolve testCompile configuration if there are is no test source to compile. There are a couple of other benefits: * the didWork flag is more accurate for these skipped tasks. * by getting rid of this self configuration, we have the potential to do the check even earlier, and skip those dependencies of the task which are not required. * similarly, we can move the validation checks earlier, ideally to just after the configuration phase. * having these effectively immutable tasks will help with parallel execution. To fix your task, you can wrap the parameter to into in a closure: into { getDeployLoc() } and get rid of the doFirst { } Longer term, we want to provide something in the dsl to let you do some task configuration only if the task is to be executed. One interesting option is to make this the default, and defer all task configuration until the task is selected for execution. That is: task myTask(...) { ... this code runs only if myTask is to be executed ... } Even more interesting if the conditional configuration code can configure stuff other than just the task in question. For example, you might do the following, instead of using gradle.taskGraph.whenReady() version = '1.0-SNAPSHOT' task release { dependsOn clean, build, upload project.version = '1.0' // or version.replaceAll('-SNAPSHOT', '') } -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
