task run order - << syntax, doLast, doFirst etc

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

task run order - << syntax, doLast, doFirst etc

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

For example:, the very first example in the groovy documentation:

task hello {
    doLast {
        println 'Hello world!'
    }
}

What is the doLast block doing in the hello task? Does this mean that
the "Hello world" printout will be the last even to occur in the hello
task?

So, if we have:


task hello {

    println 'do it then!'

    doLast {
      println 'goodbye world'
    }

    println 'do it now!'

    doFirst {
      println 'Hello world!'

    }
}


we do indeed see things done in the order

do it then!
do it now!
hello world
goodbye world
--------------------------

But what exactly is the use of determining the order of things running
WITHIN a task in this way. Shouldn't it just be iterative ... step by
step..... what comes first gets done first like in as a c program?
I ask this not in criticism, only to point out where I need the help
in understanding the new paradigm.

Another example shown in the documentation:


task hello << {
    println 'Hello Earth'
}
hello.doFirst {
    println 'Hello Venus'
}
hello.doLast {
    println 'Hello Mars'
}
hello << {
    println 'Hello Jupiter'
}


shows the output as:


> gradle -q hello
Hello Venus
Hello Earth
Hello Mars
Hello Jupiter
------------------


This completely throws me. I would have expected that "Hello Mars" is
done last   (since it is shown as a doLast).
Why is it not the case?

And I can't really find where it is documented what exactly the
difference between saying:

task hello {
 println "do this now"
}

or

task hello <<{
  println "do this now"
}

I haven't found something in the doco that explains it in ....
well,... .the way my own dull mind accepts.
Can anyone enlighten me?

thanks in advance!

sean

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

Rene Groeschke
Hi Sean,

Am 11.01.11 23:54, schrieb Sean Van Buggenum:

> 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.
>
> For example:, the very first example in the groovy documentation:
>
> task hello {
>     doLast {
>         println 'Hello world!'
>     }
> }
>
> What is the doLast block doing in the hello task? Does this mean that
> the "Hello world" printout will be the last even to occur in the hello
> task?
>
> So, if we have:
>
>
> task hello {
>
>     println 'do it then!'
>
>     doLast {
>       println 'goodbye world'
>     }
>
>     println 'do it now!'
>
>     doFirst {
>       println 'Hello world!'
>
>     }
> }
>
>
> we do indeed see things done in the order
>
> do it then!
> do it now!
> hello world
> goodbye world
> --------------------------
>
> But what exactly is the use of determining the order of things running
> WITHIN a task in this way. Shouldn't it just be iterative ... step by
> step..... what comes first gets done first like in as a c program?
> I ask this not in criticism, only to point out where I need the help
> in understanding the new paradigm.
First of all have a look at this 2 hour old thread about understanding
<< & doLast at http://bit.ly/gSceDL
A task can have multiple actions. Those actions of are organised as a
chain. doLast adds an action to the end of the chain and the doFirst
adds an action to the beginning of the chain. Everything not enclosed a
doLast or doFirst closure is executed during the configuration phase.
Everything else in the task is executed during the configuration phase
In the example above this means:
1. gradle starts configuration phase (configuring the tasks, creating
the task graph)
2. println "do it then" is executed during configuration phase
3. println "do it now" is executed during configuration phase
4. configuration phase finished and execution phase is started
(executing the tasks)
5. "hello world!' is printed as the action was added to the beginning of
the tasks action chain/list
6. "goodbye world' is printed as the action was added at the end of the
tasks action chain/list


> Another example shown in the documentation:
>
>
> task hello << {
>     println 'Hello Earth'
> }
> hello.doFirst {
>     println 'Hello Venus'
> }
> hello.doLast {
>     println 'Hello Mars'
> }
> hello << {
>     println 'Hello Jupiter'
> }
>
>
> shows the output as:
>
>
>> gradle -q hello
> Hello Venus
> Hello Earth
> Hello Mars
> Hello Jupiter
> ------------------
>
>
> This completely throws me. I would have expected that "Hello Mars" is
> done last   (since it is shown as a doLast).
> Why is it not the case?
>
With the explanation of the first example, this shouldn't thrill you
anymore. << is a shortcut for doLast

regards,
René--

------------------------------------
Rene Groeschke

[hidden email]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

svaens
Hi Rene, thanks for the reply.

"Everything not enclosed a
doLast or doFirst closure is executed during the configuration phase."

The configuration phase. This is the configuration phase for the
project, not the task right?
And there is no separate configuration phase for each task, right?
Only the project?
I ask because as a test I combined two of the previous examples I
posted before into one gradle build file, and tested.

build.gradle:
-----------------------------
task gotcha {

    println 'do it then!'

    doLast {
        println 'goodbye world'
    }

    println 'do it now!'

    doFirst {
      println 'Hello world!'

    }
}

task hello << {
    println 'Hello Earth'
}
hello.doFirst {
    println 'Hello Venus'
}
hello.doLast {
    println 'Hello Mars'
}
hello << {
    println 'Hello Jupiter'
}
--------------------------------------

output:
D:\dev\scripts>gradle hello
do it then!
do it now!
:hello
Hello Venus
Hello Earth
Hello Mars
Hello Jupiter

BUILD SUCCESSFUL

I am surprised to see "do it then!" and "do it now!" printed, since I
was running gradle hello (for the hello task) and no reference to the
gotcha task was made.
I am even more surprised, considering the above, that the gotcha
doLast and doFirst were never run.

From this I suppose I should conclude that:

--------------
task gotcha {

    println 'do it then!'

    doLast {
        println 'goodbye world'
    }
}
-------------------------------

is equivalent to :

-----------------------
println 'do it then!'
task gotcha {
    doLast {
        println 'goodbye world'
    }
}
--------------------------

is equivalent to :

--------------------------------
task gotcha {
    doLast {
        println 'goodbye world'
    }
}
println 'do it then!'
--------------------

and for a line of code not existing within a doLast or a doFirst,  it
makes no difference if it is placed within the apparent bounds of a
task or outside?
This to me is a little unexpected.... that something within a tasks {}
block can be considered some kind of global configurations phase.


Sorry if these seem like very stupid questions..

thanks

sean








On 12 January 2011 10:13, Rene Groeschke <[hidden email]> wrote:

> Hi Sean,
>
> Am 11.01.11 23:54, schrieb Sean Van Buggenum:
>> 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.
>>
>> For example:, the very first example in the groovy documentation:
>>
>> task hello {
>>     doLast {
>>         println 'Hello world!'
>>     }
>> }
>>
>> What is the doLast block doing in the hello task? Does this mean that
>> the "Hello world" printout will be the last even to occur in the hello
>> task?
>>
>> So, if we have:
>>
>>
>> task hello {
>>
>>     println 'do it then!'
>>
>>     doLast {
>>       println 'goodbye world'
>>     }
>>
>>     println 'do it now!'
>>
>>     doFirst {
>>       println 'Hello world!'
>>
>>     }
>> }
>>
>>
>> we do indeed see things done in the order
>>
>> do it then!
>> do it now!
>> hello world
>> goodbye world
>> --------------------------
>>
>> But what exactly is the use of determining the order of things running
>> WITHIN a task in this way. Shouldn't it just be iterative ... step by
>> step..... what comes first gets done first like in as a c program?
>> I ask this not in criticism, only to point out where I need the help
>> in understanding the new paradigm.
> First of all have a look at this 2 hour old thread about understanding
> << & doLast at http://bit.ly/gSceDL
> A task can have multiple actions. Those actions of are organised as a
> chain. doLast adds an action to the end of the chain and the doFirst
> adds an action to the beginning of the chain. Everything not enclosed a
> doLast or doFirst closure is executed during the configuration phase.
> Everything else in the task is executed during the configuration phase
> In the example above this means:
> 1. gradle starts configuration phase (configuring the tasks, creating
> the task graph)
> 2. println "do it then" is executed during configuration phase
> 3. println "do it now" is executed during configuration phase
> 4. configuration phase finished and execution phase is started
> (executing the tasks)
> 5. "hello world!' is printed as the action was added to the beginning of
> the tasks action chain/list
> 6. "goodbye world' is printed as the action was added at the end of the
> tasks action chain/list
>
>
>> Another example shown in the documentation:
>>
>>
>> task hello << {
>>     println 'Hello Earth'
>> }
>> hello.doFirst {
>>     println 'Hello Venus'
>> }
>> hello.doLast {
>>     println 'Hello Mars'
>> }
>> hello << {
>>     println 'Hello Jupiter'
>> }
>>
>>
>> shows the output as:
>>
>>
>>> gradle -q hello
>> Hello Venus
>> Hello Earth
>> Hello Mars
>> Hello Jupiter
>> ------------------
>>
>>
>> This completely throws me. I would have expected that "Hello Mars" is
>> done last   (since it is shown as a doLast).
>> Why is it not the case?
>>
> With the explanation of the first example, this shouldn't thrill you
> anymore. << is a shortcut for doLast
>
> regards,
> René--
>
> ------------------------------------
> Rene Groeschke
>
> [hidden email]
> http://www.breskeby.com
> http://twitter.com/breskeby
> ------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

Adam Murdoch-3
In reply to this post by svaens

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

Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

Rene Groeschke
In reply to this post by svaens
Hi,
Am 12.01.11 00:50, schrieb Sean Van Buggenum:

> Hi Rene, thanks for the reply.
>
> "Everything not enclosed a
> doLast or doFirst closure is executed during the configuration phase."
>
> The configuration phase. This is the configuration phase for the
> project, not the task right?
> And there is no separate configuration phase for each task, right?
> Only the project?
> I ask because as a test I combined two of the previous examples I
> posted before into one gradle build file, and tested.
>
> build.gradle:
> -----------------------------
> task gotcha {
>
>     println 'do it then!'
>
>     doLast {
>         println 'goodbye world'
>     }
>
>     println 'do it now!'
>
>     doFirst {
>       println 'Hello world!'
>
>     }
> }
>
> task hello << {
>     println 'Hello Earth'
> }
> hello.doFirst {
>     println 'Hello Venus'
> }
> hello.doLast {
>     println 'Hello Mars'
> }
> hello << {
>     println 'Hello Jupiter'
> }
> --------------------------------------
As mentioned in
"http://gradle.org/0.9.1/docs/userguide/build_lifecycle.html", the
configuration phase configures the objects of the project. This includes
the tasks of the object. The tasks code blocks (everything in tasks {}
except doLast and doFirst closures are executed during configuration
phase. The configuration phase calculates the DAG (see link above).
Let's take a look at your example above. simplified you can track the
execution of "gradle hello" down to the following:
> output:
> D:\dev\scripts>gradle hello
1. start configuration phase
1.1. initialise the gotcha task:
1.1.1. println 'do it then'
> do it then!
1.1.2. add the goodbye world closure to the end of gotchas task action
list without executing it
1.1.3. println 'do it now'
> do it now!
1.1.4. add the hello world closure to the beginning of gotchas task
action list without executing it
1.2. initialise the gotcha task:
1.2.1. add the hello earth closure to the end of the hello task action
list without executing it (actionlist: earth)
1.2.2. add the hello venus closure to the beginning of the hello task
action list without executing it (actionlist: venus, earth)
1.2.3. add the hello mars closure to the end of the hello task action
list without executing it (actionlist: venus, earth, mars)
1.2.4. add the hello mars closure to the end of the hello task action
list without executing it (actionlist: venus, earth, mars, jupiter)
1.3 configuration phase has finished and DAG is created (containing only
the hello task)
2. executing phase starts
2.1 execute hello task
> :hello
2.2 execute all actions in the hello actions list (venus, earth, mars,
jupiter):
2.2.1 execute closure -> println hello venus
> Hello Venus
2.2.2 execute closure -> println hello earth
> Hello Earth
2.2.3 execute closure -> println hello mars
> Hello Mars
2.2.4 execute closure -> println hello venus
> Hello Jupiter
>
> BUILD SUCCESSFUL
3. hello tasks actions completely executed




> I am surprised to see "do it then!" and "do it now!" printed, since I
> was running gradle hello (for the hello task) and no reference to the
> gotcha task was made.
> I am even more surprised, considering the above, that the gotcha
> doLast and doFirst were never run.
> >From this I suppose I should conclude that:
>
> --------------
> task gotcha {
>
>     println 'do it then!'
>
>     doLast {
>         println 'goodbye world'
>     }
> }
> -------------------------------
>
> is equivalent to :
>
> -----------------------
> println 'do it then!'
> task gotcha {
>     doLast {
>         println 'goodbye world'
>     }
> }
> --------------------------
>
> is equivalent to :
>
> --------------------------------
> task gotcha {
>     doLast {
>         println 'goodbye world'
>     }
> }
> println 'do it then!'
> --------------------
You're right. the output of all examples above should be the same. To
understand why gradle tasks have a configuration phase and a execution
phase consider the following snippet:
----------
task backup(type: Copy) {
    from jar.outputs.files
    into "backup"
}
----------
During the configuration phase of >"gradle backup", the backup tasks is
configured to copy the output of the jar task into the backup folder. As
mentioned above, gradle calculates the DAG of the build at the end of
the configuration phase. Since gradle now knows that the backup task
depends on the jar task gradle executes the task jar before the backup
task is called.

regards,
René
   
> and for a line of code not existing within a doLast or a doFirst,  it
> makes no difference if it is placed within the apparent bounds of a
> task or outside?
> This to me is a little unexpected.... that something within a tasks {}
> block can be considered some kind of global configurations phase.
>
>
> Sorry if these seem like very stupid questions..
There are no stupid questions.

> thanks
>
> sean
>
>
>
>
>
>
>
>
> On 12 January 2011 10:13, Rene Groeschke <[hidden email]> wrote:
>> Hi Sean,
>>
>> Am 11.01.11 23:54, schrieb Sean Van Buggenum:
>>> 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.
>>>
>>> For example:, the very first example in the groovy documentation:
>>>
>>> task hello {
>>>     doLast {
>>>         println 'Hello world!'
>>>     }
>>> }
>>>
>>> What is the doLast block doing in the hello task? Does this mean that
>>> the "Hello world" printout will be the last even to occur in the hello
>>> task?
>>>
>>> So, if we have:
>>>
>>>
>>> task hello {
>>>
>>>     println 'do it then!'
>>>
>>>     doLast {
>>>       println 'goodbye world'
>>>     }
>>>
>>>     println 'do it now!'
>>>
>>>     doFirst {
>>>       println 'Hello world!'
>>>
>>>     }
>>> }
>>>
>>>
>>> we do indeed see things done in the order
>>>
>>> do it then!
>>> do it now!
>>> hello world
>>> goodbye world
>>> --------------------------
>>>
>>> But what exactly is the use of determining the order of things running
>>> WITHIN a task in this way. Shouldn't it just be iterative ... step by
>>> step..... what comes first gets done first like in as a c program?
>>> I ask this not in criticism, only to point out where I need the help
>>> in understanding the new paradigm.
>> First of all have a look at this 2 hour old thread about understanding
>> << & doLast at http://bit.ly/gSceDL
>> A task can have multiple actions. Those actions of are organised as a
>> chain. doLast adds an action to the end of the chain and the doFirst
>> adds an action to the beginning of the chain. Everything not enclosed a
>> doLast or doFirst closure is executed during the configuration phase.
>> Everything else in the task is executed during the configuration phase
>> In the example above this means:
>> 1. gradle starts configuration phase (configuring the tasks, creating
>> the task graph)
>> 2. println "do it then" is executed during configuration phase
>> 3. println "do it now" is executed during configuration phase
>> 4. configuration phase finished and execution phase is started
>> (executing the tasks)
>> 5. "hello world!' is printed as the action was added to the beginning of
>> the tasks action chain/list
>> 6. "goodbye world' is printed as the action was added at the end of the
>> tasks action chain/list
>>
>>
>>> Another example shown in the documentation:
>>>
>>>
>>> task hello << {
>>>     println 'Hello Earth'
>>> }
>>> hello.doFirst {
>>>     println 'Hello Venus'
>>> }
>>> hello.doLast {
>>>     println 'Hello Mars'
>>> }
>>> hello << {
>>>     println 'Hello Jupiter'
>>> }
>>>
>>>
>>> shows the output as:
>>>
>>>
>>>> gradle -q hello
>>> Hello Venus
>>> Hello Earth
>>> Hello Mars
>>> Hello Jupiter
>>> ------------------
>>>
>>>
>>> This completely throws me. I would have expected that "Hello Mars" is
>>> done last   (since it is shown as a doLast).
>>> Why is it not the case?
>>>
>> With the explanation of the first example, this shouldn't thrill you
>> anymore. << is a shortcut for doLast
>>
>> regards,
>> René--
>>
>> ------------------------------------
>> Rene Groeschke
>>
>> [hidden email]
>> http://www.breskeby.com
>> http://twitter.com/breskeby
>> ------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
------------------------------------
Rene Groeschke

[hidden email]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

Rene Groeschke
Am 12.01.11 01:40, schrieb Rene Groeschke:

> Hi,
> Am 12.01.11 00:50, schrieb Sean Van Buggenum:
>> Hi Rene, thanks for the reply.
>>
>> "Everything not enclosed a
>> doLast or doFirst closure is executed during the configuration phase."
>>
>> The configuration phase. This is the configuration phase for the
>> project, not the task right?
>> And there is no separate configuration phase for each task, right?
>> Only the project?
>> I ask because as a test I combined two of the previous examples I
>> posted before into one gradle build file, and tested.
>>
>> build.gradle:
>> -----------------------------
>> task gotcha {
>>
>>     println 'do it then!'
>>
>>     doLast {
>>         println 'goodbye world'
>>     }
>>
>>     println 'do it now!'
>>
>>     doFirst {
>>       println 'Hello world!'
>>
>>     }
>> }
>>
>> task hello << {
>>     println 'Hello Earth'
>> }
>> hello.doFirst {
>>     println 'Hello Venus'
>> }
>> hello.doLast {
>>     println 'Hello Mars'
>> }
>> hello << {
>>     println 'Hello Jupiter'
>> }
>> --------------------------------------
> As mentioned in
> "http://gradle.org/0.9.1/docs/userguide/build_lifecycle.html", the
> configuration phase configures the objects of the project. This includes
> the tasks of the object.
Apologizes. I'm already a bit tired :-) . Of course I meant this
includes the tasks of the project.

--
------------------------------------
Rene Groeschke

[hidden email]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

svaens
Thanks very much!

Now I understand it a whole lot better. Very helpful!

sean



> Apologizes. I'm already a bit tired :-) . Of course I meant this
> includes the tasks of the project.
>
> --
> ------------------------------------
> Rene Groeschke
>
> [hidden email]
> http://www.breskeby.com
> http://twitter.com/breskeby
> ------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

Zsolt Kovacs
In reply to this post by Adam Murdoch-3
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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

svaens
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 <[hidden email]> 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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: task run order - << syntax, doLast, doFirst etc

Adam Murdoch-3
In reply to this post by Zsolt Kovacs

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 <[hidden email]> 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