gradle.build would collide with the default directory named gradle in the root
project directory containing the wrapper support jar and property files, for
projects using the wrappers of course. Less of a collision, but still not
perfect.
Maybe a compromise would be an alternative convention to call within
settings.gradle that allowed toggling between one or more "standard" naming
conventions/patterns for build.gradle files, where DEFAULT would be
build.gradle, PROJ_NAME would be ${project.name}.gradle, etc. As for the
actual implementation, maybe the include and includeFlat could take a map of
objects, where the name of the build file is supplied as a value, or a special
method that is called to set the build file name patterns. I'm not really
proposing that I know what would be best, but if you had suggestions along that
line, then maybe the "best" implementation would surface after some continued
discussion.
-Spencer
>________________________________
> From: Philip Crotwell <[email protected]>
>To: [email protected]
>Sent: Tuesday, January 31, 2012 9:18 AM
>Subject: Re: [gradle-dev] build.gradle - really?
>
>One little thing that has bothered my about the name "build.gradle" is
>that both it and the "build" directory by default start with "build"
>so tab completion in the sheel doesn't work as well. I can't tell you
>how many times I have opened the directory in vi or tried to cd into
>the build file.
>
>I know I can change it, I know it is a really small issue, but it is
>one that bites me over and over. There is value it sticking to the
>conventions, so I just deal with it, but even renaming it
>"gradle.build" would be an improvement IMHO.
>
>Philip
>
>On Sat, Jan 21, 2012 at 9:42 PM, Niclas Hedhman <[email protected]> wrote:
>> On Sun, Jan 22, 2012 at 7:19 AM, Joern Huxhorn <[email protected]>
>> wrote:
>>> The beauty of Gradle is that this isn't that important. I can always change
>>> all that structure if I'm fed up with it. It is a question of personal
>>> taste and I'm not forced to have one file for every sub-project. <3
>>
>> Exactly!!!! The model is what matters, how it gets populated is secondary.
>>
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://www.qi4j.org - New Energy for Java
>>
>> I live here; http://tinyurl.com/3xugrbk
>> I work here; http://tinyurl.com/6a2pl4j
>> I relax here; http://tinyurl.com/2cgsug
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
>
