On Oct 10, 2008, at 12:42 AM, Adam Murdoch wrote:
Hi,
Some quick questions on terminology:
In some places we refer to the 'build script', and other places we
refer to the 'build file'. Which one should we use? I don't have a
real preference, other than we use the same term consistently to
refer to this. I suspect we use 'build file' more often than 'build
script' in documentation, so perhaps 'file' is a reasonable choice.
With the -e option we can pass a String as a script without using a
file. I think build script and build file are not equivalent. For me
a build file is a file which content is used as a build script. So I
think we need both terms. Having said this, I can well imagine that
the documentation is not clean in regard to this definition. Probably
in most cases we should use build script.
Similarly, is it a 'settings file' or 'settings script'?
see above
I've added some new events to BuildListener, to represent the main
steps of initialising, configuring and executing the build. These are:
settingsEvaluated()
projectsEvaluated()
taskGraphPrepared()
I'm not happy with the name taskGraphPrepared(). I've just realised
that I use the terms 'prepare', 'populate' and 'calculate' to refer
to this step. Is 'evaluate' is a better term to use for this step,
ie taskGraphEvaluated()?
For some reason I'm not happy with evaluated. I think it is different
to projects and settings where the scripts relate more or less 1:1 to
the domain objects. The task graph is derived from this. I was also
thinking about taskGraphCreated. But after all I really like
taskGraphPopulated. It points out the fact that the task graph object
is always available but might not be populated yet. In fact we might
throw a TaskGraphNotPopulatedYetException if it is accessed to early.
Populated is more precise than prepared and calculated.
Finally, on Settings, we have a bunch of methods with 'descriptor'
in their name. I think 'project' might be a better term here, as
'project' is the meaning of the thing being referenced, whereas
'descriptor' is how they are represented. I think this reads better
in the settings file:
project('myproject').buildFileName = 'myproject.gradle'
instead of
descriptor('myproject').buildFileName = 'myproject.gradle'
Good idea. This points to a problem I don't have a good solution for
yet. I unhappy with the duplication I have introduced with those
project descriptors. We have now to tree objects and registries which
do pretty much the same things. What I want to do is to have what we
call now ProjectDescriptor as a base class for our project class. But
Project extends ProjectDescriptor does not look good. Usually you
create an actual class from a descriptor but you don't extend it.
Have you an idea for a better name than project descriptor in such a
scenario.
Another naming issue: There is the alternative of saying the build
script is executed/evaluated. I prefer the term evaluated as it is
used this way by the Groovy API and as it points out that the the
build script is not an imperative program. I'm not sure if we are
consistent here in the doc.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
