On 18/09/2012, at 8:13 AM, GitHub wrote:
> Branch: refs/heads/master
> Home: https://github.com/gradle/gradle
> Commit: d0da246b7aecc632fc90c886d6a4b3421208c840
>
> https://github.com/gradle/gradle/commit/d0da246b7aecc632fc90c886d6a4b3421208c840
> Author: Luke Daley <[email protected]>
> Date: 2012-09-17 (Mon, 17 Sep 2012)
>
> Changed paths:
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/AsmBackedClassGenerator.java
> A
> subprojects/core/src/main/groovy/org/gradle/api/internal/ClosureBackedAction.java
> A
> subprojects/core/src/testFixtures/groovy/org/gradle/api/internal/ClosureBackedActionTest.groovy
>
> Log Message:
> -----------
> Extract ClosureBackedAction to a first level class and add some test
> coverage.
>
>
> Commit: 045e919a66198ebc4985b93fb6239df129ac6a89
>
> https://github.com/gradle/gradle/commit/045e919a66198ebc4985b93fb6239df129ac6a89
> Author: Luke Daley <[email protected]>
> Date: 2012-09-17 (Mon, 17 Sep 2012)
>
> Changed paths:
> M subprojects/core/src/main/groovy/org/gradle/util/CollectionUtils.java
> M
> subprojects/core/src/test/groovy/org/gradle/util/CollectionUtilsTest.groovy
>
> Log Message:
> -----------
> collect for arrays
>
>
> Commit: 1a284bda1bb810d09c860701e052f1e6684d799f
>
> https://github.com/gradle/gradle/commit/1a284bda1bb810d09c860701e052f1e6684d799f
> Author: Luke Daley <[email protected]>
> Date: 2012-09-17 (Mon, 17 Sep 2012)
>
> Changed paths:
> A
> subprojects/core/src/main/groovy/org/gradle/api/InvalidActionClosureException.java
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/ClosureBackedAction.java
> M
> subprojects/core/src/testFixtures/groovy/org/gradle/api/internal/ClosureBackedActionTest.groovy
>
> Log Message:
> -----------
> Added explicit error handling for using an invalid closure as an action
> implementation.
>
>
> Commit: 451cc4b8cdc694c8c717080f9b13df4a1b0c2e08
>
> https://github.com/gradle/gradle/commit/451cc4b8cdc694c8c717080f9b13df4a1b0c2e08
> Author: Luke Daley <[email protected]>
> Date: 2012-09-17 (Mon, 17 Sep 2012)
>
> Changed paths:
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/AbstractClassGenerator.java
> M
> subprojects/core/src/main/groovy/org/gradle/api/internal/AsmBackedClassGenerator.java
> M subprojects/core/src/main/groovy/org/gradle/util/CollectionUtils.java
> M
> subprojects/core/src/test/groovy/org/gradle/api/internal/AsmBackedClassGeneratorGroovyTest.groovy
>
> Log Message:
> -----------
> Generate closure adapters for any method with an Action as the last
> parameter.
I'm wondering about our strategy for mixing in the DSL stuff, longer term.
It feels like we should move this out of the class generation and into a
DynamicObject implementation that the decorated class delegates to (which we
already have). We don't actually need to mix this stuff in statically, and it
might all be a bit simpler if we composed the DSL layer from a bunch of dynamic
property and method handlers (we might bust up DynamicObject into a few
separate facets to make this easier), instead of bloating out the class
generation.
Alternatively, if we do this statically, it would be nice if we could figure
out a way to mix it in earlier in the development lifecycle so that it's
available in, say, javadocs and code completion in the IDE and from static
languages and so on.
Either way, we also need to have the DSL reference understand all the mixed-in
stuff.
While we're kind of on the topic, I'm curious if anyone has some suggestions
for how a configuration DSL might be added for nested domain objects. So, say I
have:
class Thing {
ThingOptions options = new ThingOptions()
String name
}
I want methods to configure 'thing.options', but not 'thing.name', so that I
can do things like:
thing.options { option1 'foo' }
thing.options(option1: 'foo')
But I don't need to do things like:
thing.name { // what would I do here? }
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
