You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Peter Ledbrook <pe...@cacoethes.co.uk> on 2016/02/01 09:18:51 UTC
Re: API document generation
>
> The only option for standard doclets to work with Groovydoc is for
> Groovydoc to be base don the standard Javadoc API.
>
Is that something that's worth aiming for? Is it even feasible?
I'm also wondering whether others think groovydoc is just fine as it is,
since this thread has so little attention. If that's the consensus, cool.
Peter
--
Peter Ledbrook
t: @pledbrook
w: http://www.cacoethes.co.uk/
Re: API document generation
Posted by Jochen Theodorou <bl...@gmx.org>.
On 01.02.2016 16:13, Sean Gilligan wrote:
>
>>
>> I'm also wondering whether others think groovydoc is just fine as it is,
>
> It's not fine. In my opinion it's one of the biggest frustrations with Groovy. Especially the fact that you can't use it for both Java (7+) and Groovy.
>
> And Asciidoclet support would be awesome!
we can write a doctool, that can process Groovy and java... maybe even
other languages. And such a tool could then have asciidoc support of
course. I could even imagine supporting existing doclets to some extend....
But hooking into javadoc to make it know a new language is painful.
Because it means to hook into the javac compiler, produce an ast the
compiler understands and then not having proper support for extension
methods and properties or any other thing that goes beyond what java
offers. And on top of that... you are handling internal classes, which
may change in any version of java... and with jdk9 modules they might
not even be normally available anymore. For basically the same reasons I
gave up on a javac based joint compiler for Groovy.
bye Jochen
Re: API document generation
Posted by Sean Gilligan <se...@msgilligan.com>.
>
> I'm also wondering whether others think groovydoc is just fine as it is,
It's not fine. In my opinion it's one of the biggest frustrations with Groovy. Especially the fact that you can't use it for both Java (7+) and Groovy.
And Asciidoclet support would be awesome!
Re: API document generation
Posted by Andres Almiray <aa...@gmail.com>.
Well, Groovydoc is a parallel API inspired by Javadoc, so retrofitting
would entail grabbing the real Javadoc tooling API and adding extension
points that can handle Groovy syntax such as understanding properties,
closures and other stuff (such as default values in method parameters IIRC).
-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Mon, Feb 1, 2016 at 9:51 AM, Peter Ledbrook <pe...@cacoethes.co.uk>
wrote:
> I'm afraid not. Javadoc is a very specific tool that looks exclusively
>> into Java sources.
>> My experience in the past extending Groovydoc tells me the only way to
>> integrate with Javadoc tooling and doclets is to embrace and extend the
>> Javadoc API.
>>
>
> How feasible is it to retrofit Groovydoc to the Javadoc API do you think?
> I assume that's what you're saying, if not necessarily recommending.
>
> Peter
>
Re: API document generation
Posted by Peter Ledbrook <pe...@cacoethes.co.uk>.
>
> I'm afraid not. Javadoc is a very specific tool that looks exclusively
> into Java sources.
> My experience in the past extending Groovydoc tells me the only way to
> integrate with Javadoc tooling and doclets is to embrace and extend the
> Javadoc API.
>
How feasible is it to retrofit Groovydoc to the Javadoc API do you think? I
assume that's what you're saying, if not necessarily recommending.
Peter
Re: API document generation
Posted by Andres Almiray <aa...@gmail.com>.
I'm afraid not. Javadoc is a very specific tool that looks exclusively into
Java sources.
My experience in the past extending Groovydoc tells me the only way to
integrate with Javadoc tooling and doclets is to embrace and extend the
Javadoc API.
-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Mon, Feb 1, 2016 at 9:24 AM, Guillaume Laforge <gl...@gmail.com>
wrote:
> Is it possible to make JavaDoc look into non-Java sources?
> Also what about things which are not part of the JavaDoc model, like
> "properties"?
>
> On Mon, Feb 1, 2016 at 9:18 AM, Peter Ledbrook <pe...@cacoethes.co.uk>
> wrote:
>
>> The only option for standard doclets to work with Groovydoc is for
>>> Groovydoc to be base don the standard Javadoc API.
>>>
>>
>> Is that something that's worth aiming for? Is it even feasible?
>>
>> I'm also wondering whether others think groovydoc is just fine as it is,
>> since this thread has so little attention. If that's the consensus, cool.
>>
>> Peter
>>
>> --
>> Peter Ledbrook
>> t: @pledbrook
>> w: http://www.cacoethes.co.uk/
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC member
> Product Ninja & Advocate at Restlet <http://restlet.com>
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: API document generation
Posted by Guillaume Laforge <gl...@gmail.com>.
Is it possible to make JavaDoc look into non-Java sources?
Also what about things which are not part of the JavaDoc model, like
"properties"?
On Mon, Feb 1, 2016 at 9:18 AM, Peter Ledbrook <pe...@cacoethes.co.uk>
wrote:
> The only option for standard doclets to work with Groovydoc is for
>> Groovydoc to be base don the standard Javadoc API.
>>
>
> Is that something that's worth aiming for? Is it even feasible?
>
> I'm also wondering whether others think groovydoc is just fine as it is,
> since this thread has so little attention. If that's the consensus, cool.
>
> Peter
>
> --
> Peter Ledbrook
> t: @pledbrook
> w: http://www.cacoethes.co.uk/
>
--
Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>