> I think we instead want to move more of this reference stuff to the DSL guide.
Yes I like that. It would be nice if the user guide was focused around why's and dsl guide on how's. E.g. motivations, use cases, patterns in guide and property/method/task listings,etc. in dsl reference. Cheers! On Mon, Jan 30, 2012 at 7:36 AM, Adam Murdoch <[email protected]>wrote: > > On 27/01/2012, at 11:10 PM, Luke Daley wrote: > > I've deprecated the ReportingBasePluginConvention and replaced with > ReportingExtension. > > I'm unsure how to change the Java and Groovy plugin chapters in the user > guide to reflect this. They both document the old properties that have now > been deprecated. > > Should I just create a new chapter for the reporting plugin and link to it? > > > Some of the older plugins (eg java and groovy plugins) have all their > convention/extension properties documented in the user guide, but this is > mainly because they predate the DSL guide, rather than any real need for > them to be there. I think we instead want to move more of this reference > stuff to the DSL guide. > > So, I think we should add the reporting extension to the DSL guide, and > either remove the reporting properties from the java/groovy user guide > chapters or replace the old properties with the new properties in the user > guide chapters. I don't think we need to document the deprecated properties > in the user guide. > > I don't think we need a chapter on reporting yet: there's one property, > and it has a pretty reasonable default value. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
