On 27/03/2012, at 1:48 AM, Adam Murdoch wrote: > On 27/03/2012, at 11:00 AM, Luke Daley wrote: > >> >> On 27/03/2012, at 12:44 AM, Adam Murdoch wrote: >> >>> >>> On 27/03/2012, at 9:54 AM, Luke Daley wrote: >>> >>>> >>>> On 26/03/2012, at 11:41 PM, Adam Murdoch wrote: >>>> >>>>> >>>>> On 27/03/2012, at 3:00 AM, Luke Daley wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> In the future, please avoid using the list for usage questions. It is >>>>>> used to discuss the development of Gradle itself. >>>>>> >>>>>> http://forums.gradle.org is the primary support channel. >>>>>> >>>>>> Answers are inline… >>>>>> >>>>>> On 26/03/2012, at 3:56 PM, David Resnick wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I would like to upgrade to m9, but the warnings from a plugin I'm >>>>>>> using (gradle-rpm-plugin) due to internal dynamic properties use is >>>>>>> making this difficult. >>>>>>> >>>>>>> The simplest solution would be to fix the plugin, but how that should >>>>>>> be done is not clear to me. The plugin calls >>>>>>> AbstractTask.setProperty(...), which is what triggers the warnings. Is >>>>>>> there any straightforward replacement to that? >>>>>> >>>>>> «thing».ext.set(…) >>>>>> >>>>>> However, plugins should NEVER add dynamic/extra properties (they should >>>>>> add extensions). >>>>> >>>>> No. Plugins can use extra properties. They are currently the only way to >>>>> get input from the user via the command-line, for example. >>>> >>>> Fair point on the command line input. >>>> >>>>> We don't want different mechanisms for build scripts and plugins to >>>>> achieve the same thing. If a feature is available for build scripts to >>>>> use, it is quite fine for plugins to use it. And vice versa. >>>> >>>> I'm not convinced here. >>>> >>>> We can obviously never stop plugin authors from doing this, but I feel >>>> pretty strongly that we should encourage plugin authors (of plugins that >>>> are publicly distributed) to not do this and to use extensions instead. >>> >>> Why should plugin authors not use extra properties? And why should build >>> script authors use extra properties, but plugin authors use extensions? >> >> Because it makes for confusing build scripts. >> >> If the author (or thereabouts) added the property then they aren't likely to >> be confused by it in a build script. If a plugin adds dynamic properties, >> there's no hint at all where it's coming from in the build script. You have >> to rely on either reading the source code or it's (usually non existent) >> documentation. Moreover, it will be easier to aid plugin authors here by >> generating documentation for extension classes which is going to be >> difficult for extra properties. > > It feels like you might be assuming that people who use a build script == the > people who authored it, and that the people who use a plugin != the people > who authored it. This is often true, but not always.
Right, this is what the “thereabouts” was about. This isn't always true, but it's a reasonable approximation for this purpose I think. > To me, the issue is about communication across groups. Extensions offer > better options here than extra properties do, as far as discoverability, > documentation, validation and so on goes. So, if I'm a member of the release > team writing a build script for another team of 500 developers to use, I > should use an extension in the build script. And if I'm writing a plugin in > buildSrc for some personal project, then it's quite fine for me to use an > extra property. That is, the choice of mechanism should be a function of the > problem I'm solving, not whether I've chosen to use a build script or a > plugin to implement the solution. I agree with the sentiment, but I think these kinds of “rules” are helpful to plugin authors and ultimately plugin users. It's more about message and encouragement than anything else. > Over time, I think this problem goes away, as we make ad hoc extensions > simpler to define, and change more things to make use of them. Extra > properties will go away at some point, and everything will be an extension. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
