On 26/06/2013, at 6:12 AM, Justin Ryan <quidr...@gmail.com> wrote:
> 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.
That's kind of the area that we are heading in, but as always the devil is in
the details.
At the moment tasks are part of the model for at least the reason that the
model conveys dependency information through Buildable. A clean separation is
not easy, and I'm not sure it's even desired.
One of the problems with a strict separation is it makes the simple more
convoluted. It's going to force people to model more. History has shown that
most people do not do this. That's something we need to consider.
>
> 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]>
>
> On 25/06/2013, at 5:25 PM, kelemen <[hidden email]> 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]> 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
>
>
> View this message in context: Re: Lazy (task) configuration
> Sent from the gradle-dev mailing list archive at Nabble.com.
>
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
