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 <[email protected]> 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
>>
>> [email protected]
>> 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
[email protected]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
