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