On 07/03/2013, at 2:05 AM, Adam Murdoch <[email protected]> wrote:
> > > > On 7 March 2013 10:22, Luke Daley <[email protected]> wrote: > > > On 06/03/2013, at 22:11, Adam Murdoch <[email protected]> wrote: > >> >> On 06/03/2013, at 9:23 PM, Luke Daley wrote: >> >>> This was raised on the forum… >>> >>> The docs for tasks implemented in Groovy are a bit weird. Take "Jar". >>> >>> DSL: >>> http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.bundling.Jar.html >>> >>> The DSL ref doesn't show any methods inherited from Task. So if you click >>> the API Documentation link >>> (http://www.gradle.org/docs/current/groovydoc/org/gradle/api/tasks/bundling/Jar.html) >>> you get to the groovydoc. This page doesn't list any Task methods either >>> (e.g. getOutputs()). This is because these methods are implemented by >>> AbstractTask, which is internal. This also means that GroovyDoc doesn't say >>> that Jar implements Task. This is a bug in Groovydoc. In Javadoc, classes >>> in the hierarchy that are not javadoc'd are still displayed. >>> >>> Long term we need to do something about producing better documentation (of >>> which there has been discussion). >>> >>> In the meantime, I suggest we institute a rule of not writing any classes >>> that are part of the public API in Groovy. >> >> Why not just fix the dsl reference? > > Don't know why I didn't consider that. Can't see why that wouldn't work in > theory. > > We'd need to invest quite a bit in it though if its to replace the API docs. > > We're slowly working towards this. There's a lot of old content that needs to > be added, but all new stuff is added to the DSL reference as we go. There're > plenty of things we can also improve in the doc generation, but it's all > incremental stuff that we can chip away at. > > As far as the particular problem above goes, I'd push everything down to > DefaultTask and get rid of AbstractTask. Do we need to story and of this? -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
