On Sun, Feb 13, 2011 at 7:28 PM, Adam Murdoch <[email protected]> wrote:
> > On 13/02/2011, at 1:03 AM, Hans Dockter wrote: > > > > On Thu, Feb 10, 2011 at 4:10 AM, Adam Murdoch <[email protected]> wrote: > >> Hi, >> >> At the moment, you can add properties to projects and tasks (and >> dependencies, source sets, and a few other things) dynamically, simply by >> assigning a value for the property: >> >> someProp = 'value' >> assert project.hasProperty('someProp') >> >> jar.someProp = 'value' >> assert jar.hasProperty('someProp') >> >> This is all nice and convenient. However, it also causes some problems. >> Here are some examples: >> >> A typo in a property name: >> >> jar { >> basename = 'someValue' // should be baseName >> } >> >> This adds a new property 'basename' instead of setting the value of >> 'baseName'. Instead, it probably should give you an error (and suggest that >> you try 'baseName' instead). >> >> Another problem is when you use convention properties before you apply the >> corresponding plugin: >> >> sourceCompatibility = 1.6 >> apply plugin: 'java' >> >> In this case, we end up with 2 properties called 'sourceCompatibility', >> each of which is used in different places. This, of course, can be extremely >> confusing. >> >> To me, this implicit definition of properties is a nasty source of >> confusion, even to those who know Gradle well. I keep getting bitten by it, >> even now. >> >> So, I'd like to get rid of it, and require instead that dynamic properties >> are declared explicitly. >> > > Absolutely. I think this is pretty high priority. > > >> >> One question is how this should look. We already have one way to extend an >> object, using the convention object mechanism. This works for both projects >> and tasks: >> >> class MyConfigBean { >> String someProp >> List<File> someOtherProp = [] >> File someFile() { .... } >> } >> >> convention.plugins.myproperties = new MyConfigBean() >> > >> // The properties and methods of MyConfigBean are mixed in as properties >> of the project >> someOtherProp << someFile() >> println someProp >> >> This is kind of interesting as a way to declare dynamic properties, for a >> few reasons: >> >> * Plugins and build scripts would use the same mechanism >> * Bean properties can be annotated with all kinds of meta-data, such as >> validation constraints, or mappings to command-line options. >> * Bean properties can have javadoc attached, so that build documentation >> can be generated. >> * It allows both properties and methods to be defined. >> * It works well for all types of objects which need to be extended. >> * It could provide namespacing, as you could group related properties and >> methods into separate classes. >> >> The syntax is a little awkward, but might be good enough. >> > > We should definitely rethink the syntax. The '.plugins' bit is really > confusing for our scenario here. > > > Absolutely. I think we should make the actual target object more explicit: > > myTask.extendWith(MyTaskExtension.class) > > extendWith(MyProjectExtension.class) // implicit project. > > Or maybe something more like the apply statement: > > extend withType: MyProjectExtension > > myTask { > extend withType: MyTaskExtension > } > > dependencies.all { extend withType: MyDependencyExtension } > I like that. > > Or even reuse (abuse?) the apply statement: > > apply type: MyProjectExtension > Interesting idea. Not sure if this is too much overloading. We might reserve the term apply for anything that uses the API of an object to modify it. > > Also, I wonder if we should use the term 'Extension' for this capability, > rather than 'Convention'. Certainly, our conventions happen to be > implemented using extensions to our domain objects. But, you can use the > extensions to do things other than implementing a convention. > Absolutely. The term convention is very confusing for the reasons you mentioned. I think the term extension is much better. Cheers Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > > -- > Adam Murdoch > Gradle Developer > http://www.gradle.org > CTO, Gradle Inc. - Gradle Training, Support, Consulting > http://www.gradle.biz > >
