On 3 Sep 2014, at 2:29 am, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote:
> While working on the new configuration model Luke and I have noticed that we
> are not locking task container after the configuration phase so the following
> does not throw an error (even though it essentially has no useful effect):
>
> task foo {
> doFirst {
> tasks.create("bar")
> }
> }
>
> As implemented at the moment tasks references are added to the new
> configuration model based on the task container contents at the end of the
> configuration phase therefore it probably makes sense to prevent any more
> modifications to the container after that point in time.
It makes sense to prevent (or warn about) pointless creation of tasks. We do
have to be a little careful about when we lock the task container for a given
project, for backwards compatibility reasons.
Currently, any build script can define a task in any other project, so we can’t
lock until after every project build script has been executed and the
afterEvaluate() events fired. We could certainly deprecate this behaviour, but
we still need to support it.
In the future, we want to be able to interleave tasks and rules (for example,
configure my publications after I’ve generated my source to see what needs to
be published, or build my plugin and then apply it to my project).
So, we could potentially lock the task container after the DAG for the project
has been finalised, and we’re not going to consider any further tasks in that
project for execution.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
