On 14/05/10 4:18 AM, John Murph wrote:
Adam,
Along with initializer/finalizer type actions, we have found a need
for "precondition" type actions. It would work like this: once the
DAG was used to figure out all tasks that must execute, any
preconditions for all those tasks would be run. These could check
that the system/environment is configured correctly for that task.
For instance, Gradle's own build script could use a precondition to
check that the gradle_installPath property has been defined if the
"install" task will be run. If not, the build could quickly fail,
rather than run though a bunch of (potentially time consuming)
dependent tasks before reaching a task that fails because of a missing
property.
This would be a good thing, I think. The declarative validation could
make use of this, too.
One possible complication is that sometimes a setup or init task earlier
in the DAG actually does the work of configuring whatever it is that the
task needs. In which case, the precondition evaluation needs to be
deferred until after the setup task has been executed. One option here
is to remove the distinction between configuration and task execution.
For example, if we were to add the concept of a configuration task, and
treat build script execution as a configuration task, then Gradle could
evaluate preconditions once all the configuration tasks have been executed.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
