On 17/04/2013, at 11:24 PM, Adam Murdoch <adam.murd...@gradleware.com> wrote:

> 
> On 18/04/2013, at 7:49 AM, Luke Daley <luke.da...@gradle.biz> wrote:
> 
>> 
>> 
>> On 17/04/2013, at 22:22, Adam Murdoch <adam.murd...@gradleware.com> wrote:
>> 
>>> 
>>> On 18/04/2013, at 12:09 AM, Luke Daley <luke.da...@gradleware.com> wrote:
>>> 
>>>> http://forums.gradle.org/gradle/topics/reading_project_properties_triggers_configuration_of_any_deferredconfigurable_extensions
>>>> 
>>>> How do we want to deal with this?
>>> 
>>> There are several options:
>>> 
>>> 1. Asking for project.properties triggers the configuration of all deferred 
>>> objects (as it does now) and we add some stuff to make it easier to deal 
>>> with this fact. For example, we may allow the configuration of a deferred 
>>> object only when configuring some other deferred object (more or less what 
>>> the workaround does) plus some reasonable error reporting when you break 
>>> this rule.
>>> 
>>> 2. Asking for project.properties does not trigger any configuration, but 
>>> asking for a value from the map does. We add the same kinds of things as 
>>> above.
>>> 
>>> 3. Asking for project.properties returns a map with a placeholder object 
>>> for those deferred objects that have not been configured.
>>> 
>>> 4. Asking for project.properties returns a map that does not include any 
>>> deferred objects that have not been configured.
>>> 
>>> 5. Asking for project.properties does not trigger any configuration nor 
>>> does asking for a value from the map, but touching the object in some way 
>>> (accessing a property, calling a method) triggers the configuration.
>>> 
>>> I want to avoid #5 if possible, as the other options offer a stronger 
>>> guarantee (if you've got the object, it's been configured) and I don't 
>>> think we need the flexibility of #5. The other options also offer some 
>>> interesting options wrt mutability, as the object you get 
>>> post-configuration does not necessarily need to be the same object that the 
>>> configuration logic runs against.
>>> 
>>> Anyway, we can start with #1 and incrementally move to #2 and then #5 in a 
>>> relatively backwards-compatible way if we need to.
>> 
>> Do you want an issue? And/or story(s) in the spec?
> 
> Both, I reckon.

http://issues.gradle.org/browse/GRADLE-2754
https://github.com/gradle/gradle/commit/0fa2fbd8822bd114a47a061e717dcfb2a6a5c2f8

Put the story next in the queue. I started capture what you stated above but I 
don't fully understand what you mean in #1 enough to do this so left it alone.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: 
http://www.gradlesummit.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to