Hi Ken,
  thanks for the detailed reply.  it's funny but this is essentially
the solution
  i came to, and coded (perhaps a couple of hours after posting my question).
  i ended up using a task rule.  and it's a better solution because now the
  outputs of these tasks can be included in the archives artifact.
/ Eitan


On Thu, Apr 14, 2011 at 12:50 AM, Ken Sipe <[email protected]> wrote:
> Eitan,
>
> I tested an environment close to what you are looking for... I think my 
> changes are obvious, but if you need clarification please ask.  I should also 
> say that there are probably a couple of ways to solve this... this is the one 
> that came to mind to me.
>
> tasks.addRule("Pattern: package<env>: package environments") { String env ->
>        if (env.startsWith("package")) {
>                task "${env}"(type: Zip) {
>                        appendix = "${env}"
>
>                        into "catalina/${env}"
>                        from "env/${env}"
>                        /*into('lib') {
>                                                       from 
> configurations.deploy2CatalinaLib
>                                                }*/
>                }
>        }
> }
>
> task fullRelease(dependsOn:[packageBranch, packageStage, packageRelease, 
> packageProduction])
>
>
> *** I didn't have your catalina lib config... so you can see that it is 
> commented out.
>
> This approach would allow you have any number of env options... for the envs 
> you defined, the fullRelease would build all of them.  The other great 
> advantage of this approach is the a "gradle tasks" will result in good 
> documentation at the command-line... and "gradle tasks --all" will reveal all 
> the fullRelease dependencies.
>
> Hope this helps.
>
> Ken Sipe | [email protected] | blog: http://kensipe.blogspot.com
>
>
>
> On Apr 13, 2011, at 12:13 PM, Eitan Suez wrote:
>
>> [gmail crashed on my first send, sorry if it ends up getting sent twice]
>> hello,
>>
>> i'm a gradle newb.  first of all i'd like to say thank you for gradle.
>>
>> i'm trying to write a task that creates a set of zip files, one per
>> environment.  something like this:
>>
>> task packageEnvironments {
>>      description = "Package environment-specific artifacts."
>>
>>      doLast {
>>              ['branch', 'stage', 'production', 'released'].each { envName ->
>>                      println "Packaging runtime environment: ${envName}"
>>                      zip {
>>                              appendix = envName
>>                              into "catalina/${envName}"
>>                              from "env/webapp/${envName}/catalina"
>>                              into('lib') {
>>                                      from configurations.deploy2CatalinaLib
>>                              }
>>                      }
>>              }
>>      }
>> }
>>
>> except that, unlike the project.copy() action, there's no
>> project.zip() action.  i sure would like one.
>> further, i can't even figure out *how* to do this in gradle without
>> a zip action.
>> so far, i'm trying to coerce a task as an action like this:
>>
>> task packageEnvironments {
>>      description = "Package environment-specific artifacts."
>>
>>      doLast {
>>              task zipIt(type: Zip)
>>              ['branch', 'stage', 'production', 'released'].each { envName ->
>>                      println "Packaging runtime environment: ${envName}"
>>                      zipIt.configure {
>>                              appendix = envName
>>                              into "catalina/${envName}"
>>                              from "env/webapp/${envName}/catalina"
>>                              into('lib') {
>>                                      from configurations.deploy2CatalinaLib
>>                              }
>>                      }
>>                      zipIt.execute()
>>              }
>>      }
>> }
>>
>> and it doesn't work.  it produces the first zip file, but is a no-op
>> for the remainder
>> (perhaps because the inputs/outputs have already been set and perhaps are
>> immutable and so the next time around it figures the task is
>> perhaps up to date?).
>>
>> my experience *so far* with gradle is wonderful, with this one exception.
>>
>> the main disconnect i have is wanting to compose tasks,
>> wanting to invoke a task or think of a task as a function or something
>> one can parameterize.  but can't.  perhaps i shouldn't and that's fine.
>>
>> but sometimes there are all these tasks that one just wants to execute
>> and can't because they're not executable like functions are.
>>
>> perhaps what i'm asking for is action versions of the various tasks
>> that gradle exposes?  i.e. a copy action (we have), a zip action (is
>> there such
>> a thing?), an exec action (?)..
>>
>> often i find myself falling back to using an antbuilder task even when
>> a gradle equivalent exists because i can treat an ant task as an action,
>> something i can invoke with its configurations as arguments.  i.e. i
>> often cannot
>> figure out how to use the gradle equivalent properly.
>>
>> anyhow, thanks in advance for any help figuring out how to get this 'zip in
>> a for loop' task working.
>>
>> / eitan
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email


Reply via email to