On 07/03/2013, at 8:12 PM, Adam Murdoch <[email protected]> wrote:
> > > > On 7 March 2013 20:17, Luke Daley <[email protected]> wrote: > > 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? > > Perhaps just add a jira issue for the missing stuff inherited from Task. For anyone stumbling on this thread: http://issues.gradle.org/browse/GRADLE-2700 > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com -- 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
