I've come across at least one project 'in the wild' (if memory servers, I
believe it was spring-integration) that goes out of its way to change the
naming convention so that its not called 'build.gradle' but
something like "${project-name}.gradle".
That actually makes a lot of sense in a multi-project build where you might
otherwise have twenty something files each called 'build.gradle'. It can be a
bit of a pain in the
*ss to try to open the *right* build.gradle if they all have the same name.
Perhaps an interesting corollary from this story also is... if you don't like
the convention... change it... in Gradle, you can actually do that :-)
Kris
----- Original Message -----
> Interesting feedback :). Personally, I'd stick with build.gradle
> because in most of the cases we actually want to build something and
> there's a value in a slightly more precise name that describes the
> most common use case.
> Cheers!
> On Wed, Jan 18, 2012 at 10:14 AM, Tomas Roos < [email protected] >
> wrote:
> > Hey,
>
> > I was reading through the documentation today and I found the
> > following text which absolutely makes good sense!
>
> > " project does not necessarily represent a thing to be built. It
> > might represent a thing to be done, such as deploying your
> > application to staging or production environments. Don't worry if
> > this seems a little vague for now. Gradle's build-by-convention
> > support adds a more concrete definition for what a project is.
>
> > Each project is made up of one or more tasks . A task represents
> > some
> > atomic piece of work which a build performs. This might be
> > compiling
> > some classes, creating a JAR, generating javadoc, or publishing
> > some
> > archives to a repository."
>
> > how about renaming build.gradle as the standard filename looking
> > for
> > to something better ?
>
> > like project.gradle?
>
> > it could of course fallback on build.gradle to don't brake
> > compability.
>
> > otherwise it screams build and that only.
>
> > thoughts?
>
> > Tomas
>
> --
> Szczepan Faber
> Principal engineer@gradleware
> Lead@mockito
