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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
