On 24/06/2013, at 5:26 AM, kelemen <attila.keleme...@gmail.com> wrote:
> Hi, > > As asked by Luke Daley, I'm sending my notes on lazy configuration to the > dev list. The idea of lazy task confiuration is roughly described here: > http://forums.gradle.org/gradle/topics/allow_tasks_to_be_configured_just_before_execution > > I will summarize: > > As I know, you are already working on lazy configuration. I would like to > have some notes and reguests. > > 1. I believe that my proposed lazy task configuration can solve many > practical problems and is a simple concept: Easy to comprehend. In short, > lazy task configuration is a configuration block which is executed just > before the task is executed. > 2. I understand, that you want something more generic. If I can have a word > on it, I would like if you don't make something like > publications { > // lazy block > } > > This is because making some of the configuration block lazy while others > being eager (they must remain eager until Gradle 2 for backward > compatibilty), is inconsistent and very confusing. So rather, I'd prefer a > syntax like this: > > publications lazy { > // lazy block > } The goal is to eventually make all configuration lazy. So, we don't really want a DSL that has the keyword 'lazy' in it - it's just noise once everything is lazy. We also, as Luke pointed out, want a DSL that describes the what (there are some publications) rather than the how (configure these publications now, configure these publications later). This is important to allow Gradle to skip configuration that isn't required, as a declarative DSL doesn't express anything about when. The when is inferred and can be 'never'. I think there are 3 broad approaches we can take here: 1. Mix the delayed and the eager together. I know most people don't agree with me, but I think with some good diagnostics this can actually work well. Certainly don't take how it currently works as any kind of indication of the comprehensibly or otherwise of this approach, as we've only started on implementation and the approach is reliant on good diagnostics. 2. Introduce a new section in the build script to group all the delayed configuration. Some things will only be available through delayed configuration, some things will be available through both eager and delayed configuration. Over time, we would reduce the set of things available through eager configuration via deprecation. 3. Declare a DSL version in the build script. If you declare that you want eager configuration, everything is configured eagerly. If you declare that you want delayed configuration, everything is configured lazily. Some things will not be available via eager configuration. There's probably some more options we can come up with. Option #2 strikes me as probably the best option, as we make explicit in the DSL what's eager and what's not, and there's a good incremental migration path. It also means we can apply consistent DSL patterns as we expose things in this section and leave behind some of the earlier mistakes. One downside is that it leaves behind a redundant DSL section once everything has been migrated to delayed configuration. Maybe that's a good thing. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
