Hi,
Am 04.01.11 01:23, schrieb rt.rich:
> 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.
>
> 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.
What is "mySpecialCfg" in your example above? I'm not sure Configuration
is the right here. In your initial post you used an instance of
"Properties" right?
Alternativly you can write your own Task class, which inherits from the
War task:
-------
class CustomWar extends War{
Properties customProps = null;
public CustomWar(){
super()
doFirst{
//do something with the customProperties
}
}
}
//use the custom war task type
task("myWarTask", type:CustomWar){
customProps = ... //e.g. read from file
}
-------
> 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')
>
> will that get executed, now that the 'makeMyWar' task is already running?
Gradle differs between configuration phase and execution phase (see
http://gradle.org/0.9.1/docs/userguide/userguide_single.html#build_lifecycle
for more infos). In your example above, the checkSomething() method is
called during the configuration phase and 'anotherWarThingToDo' is done
in the execution phase, right after your war was created.
> 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.
>
> In any event, I really like Gradle, including the community energy around
> it.
>
> Rich
>
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
