Eitan... nice... good to hear... btw... this should work as well (which is
closer to your original intent, although I still like the rule based example)
['branch', 'stage', 'production', 'released'].each { String env ->
task "package${env}"(type: Zip) {
appendix = "${env}"
from jar.outputs.files
from ("env/${env}") {
include '**/*.txt'
}
/*into('lib') {
from
configurations.deploy2CatalinaLib
}*/
}
}
}
Ken Sipe | [email protected] | blog: http://kensipe.blogspot.com
On Apr 14, 2011, at 1:07 AM, Eitan Suez wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
