On 06/03/2013, at 11:00 AM, Szczepan Faber <[email protected]> wrote:
> On Wed, Mar 6, 2013 at 11:23 AM, Luke Daley <[email protected]> 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. > > So no plugin or task implementations in Groovy? Plugins aren't so important. They don't really have API that users use. What I am proposing does include tasks. So yes, no task impls in Groovy. Plugins and tests would be all that is left given that we don't (anymore) use Groovy for any infrastructure. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
