On 10/12/09 4:06 AM, Philip Crotwell wrote:
It is probably too late in the game for these types of questions, but here goes anyway. :) Gradle is working out really well for me, but I have one small gripe. I use bash autocomplete a lot. I also do a lot of "cd build" or "vi build.gradle" or "vi buildSrc/xyz". The gripe is that all of these start with "build" and so the autocompletion beeps for each of them. I presume the build and build.gradle names are to be similar to ant, maven uses pom.xml and target. I am not sure I have any better suggestions for them, maybe "build" could be "gradleOut" or "output.gradle" ? To be really old school and borrow from make, "build.gradle" could be "gradlefile". :)
I really don't like the fact that every build file is called 'build.gradle', for the same reason. Along similar lines, it makes it difficult to find a build file in the IDE, because they all have the same name.
The name of the build file is also a valuable source of configuration information that we're not making use of.
We talked a while ago about letting you call your build script whatever you like. The gradle command would simply look for any file that ends with .gradle, rather than a file called build.gradle. We would also use the name of the build file as the (default) name for the project, rather than using the name of the directory containing the build script. I was planning on looking at this for the Gradle 0.10 release.
I assume that buildSrc is treated differently than src because it is more like a subproject than a regular source directory, but I wonder if buildSrc could be renamed to src/build? That would have the advantage of keeping all source files in one directory.
I think this is a better place for it.
I know all these are configurable, but I really think there is great advantage to sticking to the convention for these types of things. Probably bash could be configured to know the difference as well, haven't had time to try that. As I said, it is probably too late
I don't think it's too late. We want to get this stuff right for Gradle 1.0, so now is the time to change it if it needs changing. I think in both cases we can introduce these changes in a controlled way, where we keep and deprecate the old behaviour, and remove it a few releases later.
-- Adam Murdoch Gradle Developer http://www.gradle.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
