On Mar 26, 2012, at 7:00 PM, 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.
I don't mean to get between you 2 in this conversation :) but some thoughts... 1. I agree with Luke that we should make sure usage of a plugin by build masters is not confusing 2. I agree with Adam that we should be careful where we create a non-unified approach for plugin creators and script masters It appears to me that the issue that Luke is most interested in solving is reducing confusion by the user of a plugin (please correct if I'm off)... this would be best handled by adding CLI discoverability IMO. So when I'm looking for a property... I use gradle properties. There are a number of issues with it (for a long term solution). 1st: there is no name space 2nd: It would be nice to know who was responsible for that properties... perhaps even grouped... like core, script, plugin-a, etc. 3rd: it would be nice at some point to allow meta-data on these properties... so without reading the source, you can ask gradle for help on this property and it will be what ever (if anything ) that an author provided. This is one of the important enablers of a healthy plugin eco-system IMO So in the end... I'm for allowing plugin authors to create ext properties... but the current solution doesn't make that a friendly option. ken > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com >
