This issue (configuration closures vs. execution closures) has come up many times. In general, warning you in this case is not reasonable, because task b might be e.g. a Zip type task and you are configuring it via the closure. It might still make sense for task b to depend on task a, so always warning because of this probably isn't good. There are some things Gradle might do to help, though. One is to warn about a task that is not "typed" which defines a configuration closure instead of an action closure. I can't quickly think of a reason why that would ever be useful. Anybody else have ideas? Anyone? Bueller?
On Tue, Aug 10, 2010 at 6:35 PM, Dan Tanner <[email protected]> wrote: > From the perspective of someone who's been using gradle for about a month > now (not a beginner, not an expert), I just ran into what seems like a > dangerous syntax issue. > Here's how the confusion happened: > > sample build.gradle: > ----------------- > task a << { > println 'executing a' > } > > task b(dependsOn: a) { > println 'executing b' > } > ----------------- > > Sample output of "gradle -q b": > executing b > executing a > > > My intention was that task "b" depends on task "a", so I'd expect task "a" > to be run first. It's not though, and a keen eye would notice that task b > is missing the doLast shortcut. Of course my real world situation was more > complex than this, so it took a while to notice the mistake. I guess it was > all those years of ant and maven, without the added factor of > doFirst/doLast. > > It seems to me that this situation should result in a syntax error or > warning. i.e. I can't think of a situation where I'd want a task that > depends on another task, having code that runs before the prequisite task. > Are there situations where this kind of a situation is actually desired? > -- John Murph Automated Logic Research Team
