2013/6/26 Justin Ryan [via Gradle] <
ml-node+s1045684n5711430...@n5.nabble.com>
> When I read the original email, I took it quite literally "lazy *task*
> configuration",
> emphasis on task. I don't consider the existence of tasks to be part of
> the model, and hence could come after the model is established. There is
> room to have a phase after evaluation, at which point everything is
> configured and immutable, but before the task graph is created, where then
> we can create tasks. I don't see the value of conflating configuration and
> task creation.
>
> It wouldn't solve ordering issues, but it frames things in a certain way
> that eliminates a few problem situations. I also think it's easier to
> explain to new users to Gradle:
>
> 1. Buildscript
> 2. Evaluate to build model
> 3. Read Model
> 4. Run tasks.
>
> That's not to say that more logic than task creation could happen, it
> serves as a "act upon the configuration model" phase. I understand that if
> something is in a DomainNamedCollection, I can react to things getting
> added to it via all(), but that's just one use case. I find that I want to
> look at properties on an extension to determine what tasks to create, right
> now that has to exist in an afterEvaluate block. I'd rather do it in a
> place where configuration is immutable, just so there are no surprises. I
> also can see myself writing code like
> project.plugins.withType(ThatGuysPlugin)*.whenConfigured
> { ... }, it reads nice and conveys my intent to work upon the model not
> change it.
>
> BTW, just making everything lazy just postpones the inevitable. That's
> also known as procrastination. :-)
>
I disagree with this. Laziness does solve many issues, not just postpones
them. This is because if there are no circular configuration references
(which I believe to be a design problem not solveable by Gradle), lazy
configuration naturaly creates a topological order. As a good example: When
was the last time you needed to think about the order of static
initialization between classes?
>
>
> On Tue, Jun 25, 2013 at 1:03 AM, kelemen <[hidden
> email]<http://user/SendEmail.jtp?type=node&node=5711430&i=0>
> > wrote:
>
>> So, your second proposal is different to your third in allowing mixing
>> different DSL versions? I'm not in position to decide if it is needed or
>> not. Maybe a poll would be nice to find out how many users need it.
>>
>>
>> 2013/6/25 Adam Murdoch [via Gradle] <[hidden
>> email]<http://user/SendEmail.jtp?type=node&node=5711423&i=0>
>> >
>>
>>>
>>> On 25/06/2013, at 5:25 PM, kelemen <[hidden
>>> email]<http://user/SendEmail.jtp?type=node&node=5711422&i=0>>
>>> wrote:
>>>
>>> 2013/6/25 Adam Murdoch [via Gradle] <<a
>>> href="x-msg://1435/user/SendEmail.jtp?type=node&node=5711421&i=0"
>>> target="_top" rel="nofollow" link="external">[hidden email]>
>>>
>>>
>>>> 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.
>>>
>>>
>>> Just something like a big fat block around everything:
>>>
>>> project {
>>> // this is all delayed …
>>> source { main { cpp { ... } } }
>>> publications {
>>> somePub { … }
>>> }
>>> }
>>>
>>> Everything inside the block is 'DSL 2.0' and everything outside the
>>> block is 'DSL 1.0'.
>>>
>>>
>>> --
>>> 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-tp5711393p5711422.html
>>> To unsubscribe from Lazy (task) configuration, click here.
>>> 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: Re: Lazy (task)
>> configuration<http://gradle.1045684.n5.nabble.com/Lazy-task-configuration-tp5711393p5711423.html>
>> Sent from the gradle-dev mailing list
>> archive<http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html>at
>> Nabble.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-tp5711393p5711430.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-tp5711393p5711437.html
Sent from the gradle-dev mailing list archive at Nabble.com.
