On Mon, Mar 4, 2013 at 1:18 PM, Luke Daley <luke.da...@gradleware.com>wrote:
> [...] > That's really exciting to hear (read?). > Both read and hear I guess ;-) > Perhaps we should consider joining forces on this to create something > quite powerful that we could use to replace our DSL reference as well. If > the new tool could be augmented with plugins that can add descriptions of > dynamic behaviour (e.g. mixins, runtime decorations etc.) then this might > be a possibility. > We haven't yet scheduled working on GroovyDoc, but it's definitely something we'd like to do for having a nicer looking javadoc documentation, that should work for both Groovy and Java sources. So a joint effort would be most welcome as it's difficult to stretch ourselves on too many fronts at the same time :-) We're happy to discuss requirements, possible approaches, etc, as you see fit. Guillaume > > > > > So that's more 2. and 3. of your options here. > > > > Looking forward to reading this thread. > > > > Guillaume > > > > > > On Mon, Mar 4, 2013 at 12:56 PM, Luke Daley <luke.da...@gradleware.com> > wrote: > > Hi, > > > > I think we should consider what to do about this at some point. > Groovydoc just doesn't cut it and having the API doc spread over two places > is no good. > > > > I think we have three options: > > > > 1. Only use Java for any public API (i.e. anything that ends up in the > api docs) > > 2. Fix Groovydoc so that it can replace our Javadoc > > 3. Invent something new > > > > #1 is the “easiest” I guess, but it doesn't solve the problem for our > users. I'm not sure we can say: “if you want decent API doc, implement in > Java”. One way to sidestep this is to advocate the use of interfaces for > the public API, but this breaks down for tasks at least (for now). > > > > I'm not suggesting we do anything right now, but I wouldn't mind having > an idea of where we are going with this. > > > > -- > > Luke Daley > > Principal Engineer, Gradleware > > http://gradleware.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > -- > > Guillaume Laforge > > Groovy Project Manager > > SpringSource, a division of VMware > > > > Blog: http://glaforge.appspot.com/ > > Social: @glaforge / Google+ > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Guillaume Laforge Groovy Project Manager SpringSource, a division of VMware Blog: http://glaforge.appspot.com/ Social: @glaforge <http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
