On 12/01/2011, at 7:11 PM, Zsolt Kovacs 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.
That would be excellent. Have a look at the wiki for some details of how to build and patch the docs: http://docs.codehaus.org/display/GRADLE/How+to+build+the+documentation > > 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 > > -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
