Is there a 0.9 user guide (somewhat) completed?

I love gradle, but i've certainly solved most problems on this mailing list and 
not with the 0.8 user guide :)

Roger

On Feb 20, 2010, at 8:37 PM, Paul Speed wrote:

> From me perspective,
> Yes, it's very usable... and you might as well get over some of the "breaking 
> changes" now.
> 
> Also, yes, you are asking for pain by adopting early but I think the gain is 
> worth it. (and ultimately you will suffer the pain anyway.)
> 
> Our biggest problem is just keeping our whole team on the same version so 
> that someone's little quirk won't be blamed on gradle.
> 
> -Paul
> 
> phil swenson wrote:
>> thanks for the excellent answers!
>> is 0.9 usable?  Should I grab the latest and greatest or am I asking
>> for pain by adopting too early?
>> On Sat, Feb 20, 2010 at 2:23 PM, Adam Murdoch <[email protected]> 
>> wrote:
>>> 
>>> On 21/02/10 2:10 AM, phil swenson wrote:
>>>> One thing I don't like about most of the build systems is they tend to
>>>> end up being monster files.
>>>> 
>>>> In Ruby's, they let you drop a .rake file in a tasks directory and
>>>> rake tasks in there automatically are added to the main scope of rake.
>>>> 
>>>> What I'd really like are a bunch of different files based on their
>>>> functionality:
>>>> 
>>>> test.gradle, automation.gradle, etc
>>>> 
>>>> I know in 0.9 gradle is making it easier to add a bunch of groovy
>>>> classes to be imported by gradle,
>>> Actually, in 0.9 we are making it easier to import other build scripts. So,
>>> in your case, you could do:
>>> 
>>> apply url: 'test.gradle'
>>> apply url: 'automation.gradle'
>>> 
>>> or even
>>> 
>>> fileTree(projectDir).include('*.gradle').each { file ->
>>>   apply url: file
>>> }
>>> 
>>> 
>>>> so maybe my focus should be having
>>>> leaner build.gradle and push out all the logic to groovy classes... ?
>>>> 
>>> Either would be possible, but I think using multiple build scripts is
>>> probably a better option, as the complete build DSL is available to you.
>>> 
>>>> also (more importantly), as we are a product company, we have several
>>>> branches of code we work on simultaneously.  I would also like to have
>>>> a master gradle build file and depending on which branch is active,
>>>> have the gradle build file pull in branch specific tasks.  So I would
>>>> look at a properties file, see what branch is active and pull in tasks
>>>> to gradle from this branch.
>>>> 
>>> You could certainly do this:
>>> 
>>> def branch = ... // figure out the path to the active branch
>>> apply url: "$branch/tasks.gradle"
>>> 
>>> 
>>> --
>>> Adam Murdoch
>>> Gradle Developer
>>> http://www.gradle.org
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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


Reply via email to