Hi Luke, I'm not advocating any of those options... but I'm definitely interested in the discussion!
As part of the coming Groovy documentation and website overall initiative, I'm thinking GroovyDoc should get a facelift, if only from a look'n feel perspective (think nicer skin, some basic javascript interactivity and indexing...), but that it should cope well with both Java and Groovy alike, so users could really use just one tool. 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 <http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>
