On 27/12/09 6:13 PM, tbee wrote:
Thank you very much for such a detailled explanation.
John Murph wrote:
I mentioned in my previous post that I changed your code from an
"execution
closure" to a "configuration closure". That is what the "<<" does.
Finally, to fully understand the error you are seeing, you need one more
piece of information. The "<<" is just shorthand for doLast.
Understood. I'm slowly piecing it together. Going back to the documentation,
this would be identical then:
tasks.add(name: 'copy', type: Copy).configure {
...
}.doLast {
...
}
About the "<<"; in my opinion shortcuts are always things that have a
certain risc. Replacing ".doLast" with "<<" saves 4 characters, but"<<"
does (in a generic sense) not really symbolize "last". It more resembles
"previous", "rewind" or "redirect in". At least that is how I was reading
it. So I'm not sure saving 4 characters is worth the less obvious notation.
A better symbol would have been ">|", but I understand that Groovy puts
syntactical restrictions on Gradle's domain language. Knowing this, I will
be using the more explicit methods instead.
BTW, I would expect "execute" instead of "doLast". "doLast" is more like an
event thing, instead of the main body of the action.
This is good feedback. We plan on reworking the task DSL to take this
kind of feedback into account, sometime before the 1.0 release, possibly
in the 0.10 release. We also plan on improving the tutorials some time
soon, to better cover some of the conceptual stuff.
I think the << syntax is a failed experiment. It's just too confusing,
relative to the benefit we get. We should get rid of it. We would still
need the concepts (i.e. there's some code in a closure which executes
straight away to configure the task, and there's some code in a closure
which executes later when the task is executed), but hopefully we can
come up with a DSL which makes this more explicit.
I also agree that something like execute { } is a better option than
doLast {} or doFirst {}. In fact, I think we should do away with task
actions altogether, and replace them with better ways to wire tasks
together.
John Murph wrote:
As to why uploadArchives doesn't need the configuration to be set, this is
part of what the Java plugin does for you. I don't remember for sure, but
I
think it just finds all configurations and makes an upload<config name>
task
for each one, associating the task with the configuration automatically.
The archives configuration is a default configuration to which the result
of
all "Jar" and "Zip" and "Tar" type tasks are automatically added. Those
two
automatic actions are fairly mundane, but the combination result is a bit
"magical."
My two posts back message showed code I took from the Upload task; it
explicitly sets the correct configuration.
Slowly removing the syntactic sugar (<< becomes doLast) makes my build
script more easily readble IMHO. But the whole configurations thing is
indeed something mystical. I pieced what I have now together with some copy
and pasting from google.
John Murph wrote:
As for the user guide, we
have discussed the need for an improved "beginners guide" before, but it's
one thing to say it's needed, and another altogether to write it.
I understand, although writing posts like the ones you did for me, also
takes time :-)
What I would suggest Gradle needs, is a conceptual overview. What are these
configurations? And the stuff about tasks having a configuration moment and
an execution moment. But I can imagine it is hard to explain in a document.
Maybe each task also should describe what it does from an configuration and
execution point of view. So zip: setups up x, y z, adds the jar to
configuration.archives, generates zip file. ANT also describes the tasks in
such a way.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
