On 04/01/2011, at 11:23 AM, rt.rich wrote:
>
> Rene, I apologize for taking a while to follow up. I have been working on a
> number of other issues in my build, which I have fixed. Anyway, thank you!
> It now builds a separate .war file for each run-time configuration.
>
> So far, my experience with Gradle has been positive, but I wanted to share
> some things that I think may be stumbling blocks for other adopters:
>
> 1. At a basic syntax level, I found myself getting tripped up by subtle, but
> important differences in the Gradle DSL and Groovy syntax. It wasn't always
> clear to me when I should specify a setting by using one of the lines
>
> setting: 'value'
> setting 'value'
> setting = 'value'
> setting('value')
>
> or a variation of those. I think this has already been discussed on the
> list, and there is an effort to clarify it in the documentation.
Over time, ideally before Gradle 1.0 is out, we will standardise on one of
these forms, probably the second one.
>
> 2. I wish I could pass arguments to tasks, but there doesn't seem to be a
> way to do that. For example, I had initially thought I could do something
> like:
> task makeMyWar(Type: War, mySpecialCfg)
> and 'mySpecialCfg' would be scoped inside the task. Is the only alternative
> to use global-scoped variables (notably, Configurations)? Anyway, I found
> myself writing plain old Groovy methods to do some pieces of work, and then
> passing in arguments from my invoked Tasks.
>
> 3. I don't really get the precise semantics of Task execution, as regarding
> when adding dependent tasks to an existing task, and also when adding
> individual Gradle (or Groovy) bits of code to a templated-task. For
> example, if I have a task defined as
> task makeMyWar(Type: War) {
> println "checking something"
> checkSomething()
> // and then specify options for running a 'War' task
> baseName = "foo"
> from("bar") {
> ....
> }
> }
>
> and I have the checkSomething() method do a
> tasks['makeMyWar'].doLast('anotherWarThingToDo')
There are a few different points during a build when the code related to a task
executes. The first is at configuration time. The code in the closure provided
to the task definition is executed at this time, ie when the build script
executes. This configures the task. It doesn't execute the task. The
configuration code is executed for every build, regardless of whether the task
will be executed or not.
The other interesting time is task execution. A task has a list of actions,
which are executed in the order specified at this time. Task.doFirst() and
doLast() add actions to the start and end of the list, respectively. They do
not add task dependencies. So, the above won't work - it won't even compile.
You can't add actions to a task once it is executing.
>
> will that get executed, now that the 'makeMyWar' task is already running?
>
> Also, what are the semantics of adding arbitrary Groovy commands to a Gradle
> task, as I do above? Can I intersperse those commands in between the
> specifiers for the settings on the task? Are there any that are disallowed?
> Would that change the order of execution? The behavioral differences between
> configuration settings on a task and interspersed Groovy operators and/or
> object method-calls is not quite clear to me.
They're all the same thing: method calls on the task instance, which execute at
configuration time to configure the task. Task.doFirst() and doLast() configure
the task: they add code to be executed later, when the task executes.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
