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. 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. 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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
