Thanks for the clarification John. I hadn't paid enough attention to that part of the docs. I didn't realize the significance of the before and after hook timing...it almost seems like the configuration closures should be called something other than a task - e.g. config or something like that, leaving execution closures dedicated to the task keyword. I presume that's already been discussed in the past though, and there are some good reasons for the current design.
Anyway, here are some documentation ideas that might lessen the learning curve for others: - Would it help to have a quick note in the getting started about the syntax difference, pointing to either the build lifecycle chapter and/or the B.2. traps section? - Would it help move up the build lifecycle chapter? It's currently back near the more advanced topics, when it sounds like this is a common newbie mistake. Thanks again, Dan On Tue, Aug 10, 2010 at 7:01 PM, John Murph <[email protected]> wrote: > 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 >
