Hi Adam, thanks also for the explanation. It is very helpful. It is great to know we beginners have such support from the community, and development at that!
sean On 12 January 2011 19:11, Zsolt Kovacs <[email protected]> wrote: > Hi Adam, > This was truly helpful so this very same explanation should be added to > chapter 5.1 of the user guide. I am using gradle for some time but not full > time :(, but somehow the relationship between doLast() and execution phase > did not sink in. Those phases are only mentioned in 'Configure by DAG' > chapter, which probably a bit too too late ... > In my mind ant also has these 2 phases because it parses the xml file > (configuration phase) before it executes it. And this is actually the heart > of gradle, is not it :). This might be also useful to mention. > I can do this changes, just let me know how. > Kovax > > On 12 January 2011 01:25, Adam Murdoch <[email protected]> wrote: >> >> On 12/01/2011, at 9:54 AM, Sean Van Buggenum wrote: >> >> Hi all, >> >> I am new to gradle, and am having troubles understanding the order in >> which tasks are run, and what the various keywords (as obvious as they >> sound) actually mean. >> >> There are 2 things to know, which might make this clearer: >> * There are 2 different points in time when code related to a task is >> executed: The first is configuration time, which is when the build script >> executes. The idea is that at this time you configure the task, so that it >> does the right thing at the other point in time, namely, execution time. >> Execution time is the point in time where the task does its actual work, and >> happens only if the task is selected for execution, and after its >> dependencies have executed. >> * Each task has a sequence of actions, which are run in the order >> specified when the task executes. An action is simply a closure or an Action >> implementation. The doFirst() method configures the task to add an action at >> the start of the sequence. The doLast() and << methods configure the task to >> add an action at the end of the sequence. >> The generic form for a task definition is: >> task hello(type: SomeType) { >> // this code executes at configuration time, regardless of whether the >> task is scheduled for execution >> } >> The type declaration and the configuration closure are optional. If you >> leave out the type declaration, you get a DefaultTask instance. >> Sometimes you need to add some behaviour to the task. Sometimes you don't. >> To add behaviour, you configure the task to add some actions, using >> doFirst() or doLast(): >> task hello { >> // add an action. The action is added at configuration time, but will >> only execute at execution time >> doLast { >> println 'the task is executing' >> } >> } >> Finally, there is a shortcut form for the above: >> task hello << { >> println 'the task is executing' >> } >> At the risk of confusing things again: >> We're not 100% happy with this syntax. I think that at some point, we will >> deprecate and remove this shortcut form as it just doesn't seem to be worth >> the confusion it causes. >> We are also toying with the idea of deprecating and removing actions, as >> well. We'd keep the goodness that doFirst() and doLast() provide, but have >> it so that you use tasks instead. This way, there are only tasks. >> However, there will be plenty of warning before this happens, so feel free >> to use any or all of the above. >> >> -- >> Adam Murdoch >> Gradle Developer >> http://www.gradle.org >> CTO, Gradle Inc. - Gradle Training, Support, Consulting >> http://www.gradle.biz >> > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
