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