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. :-)
On Tue, Jun 25, 2013 at 1:03 AM, kelemen <attila.keleme...@gmail.com> 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.
>
