This is another small step towards a cross-cutting DSL. The idea is that when you define a hook point, you add a method that takes an Action<SomeType> to the API, so that the hook is usable from java and other not-groovy languages, and the DSL mapping takes care of making it easier to use from the DSL. Also useful for factory methods such as RepositoryHandler.ivy(Action) and friends.
I'll update the DSL reference guide generation at some point soon to take this (and the 'set method', ie the generated void <propName>(value) method) into account. One question is how should we figure out which types are decorated, for the purposes of documenting this behaviour in the DSL guide? Some manual markup in the <type>.xml source page? An annotation on the type? Assume everything in the DSL guide is decorated (it should be), and manually check for and fix those that are not? Another question is what to do with those existing hook points which have both void hookPoint(Action) and void hookPoint(Closure), now that we don't need the hookPoint(Closure) overload. I guess we leave the redundant method, and at some point deprecate and remove them from the API (but not the DSL, of course). I'd like to tidy-up a few more patterns at some point: * Factory methods. If we have T someThing(Action<T>), mix in T someAction(Closure) and T someAction(Map<String, ?>). I wonder if we should annotate the factory methods, and only decorate those methods that are annotated? * Configure methods. If we have T getSomeProperty(), mix in void someProperty(Closure) and void someProperty(Map<String, ?>). Again, I wonder if we should annotate these properties as 'nested dsl elements', and only decorate those methods? * Multi-valued properties. If we have T getSomeProperty() and void setSomeProperty(T), where T is a multi-valued type with element type E, then mix in void someProperty(E...), void someProperty(Iterable<? extends E>) and so on. * Properties of type File. If we have void setSomeProperty(File), mix in void setSomeProperty(Object). One question is how to figure out what base directory to use to convert these values. One option would be that every domain object created within a project would use that project's base directory. Begin forwarded message: > From: [email protected] > Date: 25 November 2011 10:21:58 AM AEDT > To: [email protected] > Subject: [gradle-scm] [gradle/gradle] 2c4578: - Added ExtensionAware which > all decorated classes... > Reply-To: [email protected] > > Branch: refs/heads/master > Home: https://github.com/gradle/gradle > > Commit: 2c45784bd14aecfbe82ebd2e641f11297e37d000 > > https://github.com/gradle/gradle/commit/2c45784bd14aecfbe82ebd2e641f11297e37d000 > Author: Adam Murdoch <[email protected]> > Date: 2011-11-24 (Thu, 24 Nov 2011) > > Changed paths: > M subprojects/core/src/main/groovy/org/gradle/api/Project.java > M subprojects/core/src/main/groovy/org/gradle/api/Task.java > 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/api/internal/GroovySourceGenerationBackedClassGenerator.java > A subprojects/core/src/main/groovy/org/gradle/api/plugins/ExtensionAware.java > M > subprojects/core/src/main/groovy/org/gradle/api/plugins/ExtensionContainer.java > M > subprojects/core/src/test/groovy/org/gradle/api/internal/AbstractClassGeneratorTest.java > M subprojects/docs/src/docs/dsl/dsl.xml > A subprojects/docs/src/docs/dsl/org.gradle.api.plugins.ExtensionAware.xml > M > subprojects/integ-test/src/integTest/groovy/org/gradle/integtests/DynamicObjectIntegrationTest.groovy > > Log Message: > ----------- > - Added ExtensionAware which all decorated classes implement. > - Fixed AsmBackClassGenerator so that it correctly adds set methods for > properties with primitive type, properties from @NoConventionMapping classes, > properties with a final getter method, and write-only properties. > > > Commit: 2e69764a681a0aaaedf8801203ad0d97cd9d3585 > > https://github.com/gradle/gradle/commit/2e69764a681a0aaaedf8801203ad0d97cd9d3585 > Author: Adam Murdoch <[email protected]> > Date: 2011-11-24 (Thu, 24 Nov 2011) > > 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 > R > subprojects/core/src/main/groovy/org/gradle/api/internal/GroovySourceGenerationBackedClassGenerator.java > M > subprojects/core/src/test/groovy/org/gradle/api/internal/AbstractClassGeneratorTest.java > R > subprojects/core/src/test/groovy/org/gradle/api/internal/GroovySourceGenerationBackedClassGeneratorTest.java > M > subprojects/integ-test/src/integTest/groovy/org/gradle/integtests/DynamicObjectIntegrationTest.groovy > > Log Message: > ----------- > Changed class generation to add an overloaded method that accepts a Closure, > for each method that accepts an Action. That is, for void > someHookPoint(Action<SomeType>), automatically add void someHookPoint(Closure > cl). > > > Compare: https://github.com/gradle/gradle/compare/554dee0...2e69764 > > <hr/> > <p> > To unsubscribe from this list please visit: > </p> > <p> > <a > href="http://xircles.codehaus.org/manage_email";>http://xircles.codehaus.org/manage_email</a> > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
