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.
