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.
