2013/6/25 Adam Murdoch [via Gradle] < ml-node+s1045684n5711418...@n5.nabble.com>
> > On 24/06/2013, at 5:26 AM, kelemen <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711418&i=0>> > 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. > > It's not that mixing them is bad but it should be easy to distinguish between eager and lazy configuration. Such as a keyword (if not for lazy, then eager). > 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. > > I'm not sure what you actually mean in grouping configurations but somehow I feel that it might be too much noise. > 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. > > I like this solution. It could be in settings.gradle or gradle.properties (as with many new features). Also, this could be a standard way in evolving Gradle. If you truly want a version number, then I think settings.gradle would be preferable to gradle.properties. A version number would prevent upgarding in some parts while staying with others but I'm not sure that this is a bad thing. > 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 > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gradle.1045684.n5.nabble.com/Lazy-task-configuration-tp5711393p5711418.html > To unsubscribe from Lazy (task) configuration, click > here<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5711393&code=YXR0aWxhLmtlbGVtZW44NUBnbWFpbC5jb218NTcxMTM5M3wtMTMxMjM2NTcwMA==> > . > NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gradle.1045684.n5.nabble.com/Lazy-task-configuration-tp5711393p5711421.html Sent from the gradle-dev mailing list archive at Nabble.com.
