On 24 June 2013 08:18, kelemen <attila.keleme...@gmail.com> wrote: > 2013/6/24 Daz DeBoer-2 [via Gradle] <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711411&i=0> > > > >> I think we're in general agreement that the implicit lazy syntax used by >> the publishing extension is not a model we want to continue to pursue. That >> said, we're looking for a bigger solution than simple task configuration >> laziness. This is what we're focused on, and we're unlikely to look at lazy >> task configuration as a separate concern until we've got a better idea of >> the big picture. >> >> For now, you can achieve the pattern you are looking for by using a >> "configuration task": this is a separate task that your main task depends >> on, which when executed does the work of configuring the main task. >> > > I do use "configuration task" to work around the problem but this still > needs the "afterEvaluate" because the configuration task needs the same > dependencies as the task it configures. This is, because the config task > may read the property of another task which is also lazily configured > (using a config task). Having the same dependencies (except for itself) > will implicitly create a dependency between these configuration tasks as > well. Regardless, I hope to see what you come up with. Is there schedule (a > Gradle version number) for this lazy configuration? >
We are actively working on lazy configuration as part of the ongoing C++ development. There's no particular release that is targeted for this, as it's likely to be incrementally developed over the coming releases. Once we've got a model that works well for C++, we're likely to distill those concepts into something more abstract that can be reused elsewhere. -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com
