You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Jeremy Huiskamp <jh...@uoguelph.ca> on 2006/02/09 17:45:56 UTC
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
What would be the suggested route for coming up with a javadoc tool?
Is there something out there now that could be imported and shaped
up? At the other extreme, I'm envisioning busting out jflex/cup and
doing a from-scratch implementation. I'm thinking there would be a
lot of overlapping functionality with the front end of a compiler so
should the two tools be considered together? Harmony doesn't have a
start on it's own compiler yet, correct?
Jeremy
On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
> Ok - this isn't about the finer points of confusion surrounding
> documentation....
>
> We need a javadoc tool for Harmony.
>
> The current conversation is a diversion from this, which I recall
> was the original motivation behind the current generation of this
> discussion.
>
> So, anyone interested? We need all the tooling actually...
>
> geir
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
indeed. We're lazy.
geir
Tim Ellison wrote:
> ... and it goes without saying that if gjdoc were dual
> licensed/contributed we'd welcome it with open arms.
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
>> Because distributing software under the GPL is a non-starter for us.
>>
>> Anthony Green wrote:
>>> On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote:
>>>> We were planning to just use the eclipse compiler. No reason to
>>>> rewrite.
>>> Didn't you just write in this thread that you need "all the tooling"?
>>> What makes the compiler special? If you can non-Apache FOSS licensed
>>> tools, why not just use the excellent gjdoc for your javadoc tool?
>>>
>>> http://www.gnu.org/software/classpath/cp-tools/
>>>
>>> AG
>>>
>>>
>>>
>
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Tim Ellison <t....@gmail.com>.
... and it goes without saying that if gjdoc were dual
licensed/contributed we'd welcome it with open arms.
Regards,
Tim
Geir Magnusson Jr wrote:
> Because distributing software under the GPL is a non-starter for us.
>
> Anthony Green wrote:
>> On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote:
>>> We were planning to just use the eclipse compiler. No reason to
>>> rewrite.
>>
>> Didn't you just write in this thread that you need "all the tooling"?
>> What makes the compiler special? If you can non-Apache FOSS licensed
>> tools, why not just use the excellent gjdoc for your javadoc tool?
>>
>> http://www.gnu.org/software/classpath/cp-tools/
>>
>> AG
>>
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Because distributing software under the GPL is a non-starter for us.
Anthony Green wrote:
> On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote:
>> We were planning to just use the eclipse compiler. No reason to rewrite.
>
> Didn't you just write in this thread that you need "all the tooling"?
> What makes the compiler special? If you can non-Apache FOSS licensed
> tools, why not just use the excellent gjdoc for your javadoc tool?
>
> http://www.gnu.org/software/classpath/cp-tools/
>
> AG
>
>
>
ASF Licensing policy and the EPL (was: javadoc something something...)
Posted by Leo Simons <ma...@leosimons.com>.
Hi all,
On Thu, Feb 09, 2006 at 11:56:56PM -0500, Jeremy Huiskamp wrote:
> I was wondering about this myself. I went and slogged through the
> epl and had trouble gathering exactly what the license restrictions
> were. From what I could tell, most of it was just disclaimer.
Nah, besides all the disclaimer stuff and the granting of various rights
there's also some "viralness" in there. The EPL is "completely" viral for
source code, and for object form, relicensing is explicitly allowed but
requires a notice with the software that source code is available. However,
even then, the "viralness" is restricted completely to the EPL-ed software
and/or any derivative works.
For example, if you have a javadoc tool licensed under the EPL, a doclet
would not be a derivative work, hence you could ship the doclet with the
object form version of the EPL and the EPL would not apply to the doclet.
I think. IANAL. Not legal advice. Blah.
> What is the official apache stance on epl code?
>
> On 9-Feb-06, at 11:48 PM, Anthony Green wrote:
>
> >On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote:
> >>We were planning to just use the eclipse compiler. No reason to
> >>rewrite.
> >
> >Didn't you just write in this thread that you need "all the tooling"?
> >What makes the compiler special?
Nothing.
> If you can non-Apache FOSS licensed
> >tools, why not just use the excellent gjdoc for your javadoc tool?
> >
> >http://www.gnu.org/software/classpath/cp-tools/
For licensing reasons, and for licensing reasons only.
Apache does not yet have an "official stance" on the EPL license nor on
the GPL+Exception license for GNU Classpath, but we're getting quite
close to having a detailed, official and clear-worded policy on most of
this. Unfortunately, the precise information is all still restricted to
private mailing lists but that will also change soon (fingers crossed).
IIRC, Apache projects will be allowed to redistribute EPL-licensed
software in binary form. The situation with GPL (exception or not) is
more involved, and goes further than just the virality and patent
clause problems we've extensively discussed before. (I think sublicensing
is one of the key bits).
Note that "redistribute" is different from "use". (I just answered the
question for redistribution since I'm guessing it is part of what you
meant here.) Even right now, before there is any kind of new policy, there
is nothing stopping us from *using* gjdoc, just as there is nothing
stopping us from using GCC.
cheers,
Leo
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Jeremy Huiskamp <jh...@uoguelph.ca>.
I was wondering about this myself. I went and slogged through the
epl and had trouble gathering exactly what the license restrictions
were. From what I could tell, most of it was just disclaimer. What
is the official apache stance on epl code?
Jeremy
On 9-Feb-06, at 11:48 PM, Anthony Green wrote:
> On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote:
>> We were planning to just use the eclipse compiler. No reason to
>> rewrite.
>
> Didn't you just write in this thread that you need "all the tooling"?
> What makes the compiler special? If you can non-Apache FOSS licensed
> tools, why not just use the excellent gjdoc for your javadoc tool?
>
> http://www.gnu.org/software/classpath/cp-tools/
>
> AG
>
>
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the
debate...)
Posted by Anthony Green <gr...@redhat.com>.
On Thu, 2006-02-09 at 13:41 -0500, Geir Magnusson Jr wrote:
> We were planning to just use the eclipse compiler. No reason to rewrite.
Didn't you just write in this thread that you need "all the tooling"?
What makes the compiler special? If you can non-Apache FOSS licensed
tools, why not just use the excellent gjdoc for your javadoc tool?
http://www.gnu.org/software/classpath/cp-tools/
AG
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by George Harley <ge...@googlemail.com>.
Hi Jeremy,
Whatever you feel like doing will be better than nothing.
(Sorry, I couldn't resist it)
George
IBM UK
Jeremy Huiskamp wrote:
> First the disclaimer: I have zero experience with writing such tools
> and precious little with compilers. I'm just spewing what I think but
> if there are accepted ways of doing these things, it'd be great for
> anyone to step in and school me. I'm here to learn, hopefully by
> contributing :)
>
> What I'm thinking (and maybe this is dead obvious) is that there are
> lots of high level tasks that javac and javadoc will have in common:
> -understanding and parsing the syntax of the language itself
> -the relevant parts of that are anything that you can javadoc: types,
> fields, methods...
> -the relation of classes in a package hierarchy, like when a method
> takes an @arg of type java.lang.String, you've got to resolve that and
> produce a link to the String javadoc
> -essentially having the ability to take a target dir and produce a
> walkable data structure of all it's contents
>
> Of course, it's not a perfect match. Javadoc needs to treat javadoc
> comments as different from other comments (not toss them) and it
> doesn't need to understand things at a level finer than, say, methods
> (doesn't need to know about if statements, loops, etc). But there's
> enough there that the javadoc front end could essentially be the javac
> frontend with the addition of handling the actual javadoc contents.
> Then, of course, the back end of the compiler spits out .class files
> while javadoc spits out html or whatever other format you need, but
> that's the reason for the separation between front and back ends :)
>
> What I could do is take the eclipse compiler and see what parts of it
> can be reused. I don't know anything about it so I won't offer any
> speculation now. Also, obviously eclipse has it's own javadoc
> functionality. Is that something that can be borrowed?
>
> Assuming the easy case, that the tools are all there for poaching with
> minimal work, what would the proper action be? It could be stated
> that harmony will use the eclipse tools and you should go get them
> from eclipse if you want them (at least for the time being, until
> harmony gets to the point of being packaged up as a useable jdk). I
> gather that's the current status of the compiler. Or harmony could
> host the currently accepted binaries. Or the source code could be
> taken into svn, in which case there's the question of keeping in sync
> with the original tool. In all likelihood, it won't be that simple
> and harmony will have some of it's own modifications...
>
> Having asked so many questions, I'm now expecting to be told that
> whatever I feel like doing will be better than nothing :-p I'm off to
> see what I can find out about the eclipse toolset.
> Jeremy
>
> On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote:
>
>>
>>
>> Jeremy Huiskamp wrote:
>>> What would be the suggested route for coming up with a javadoc tool?
>>
>> Open up an editor, and start typing! :)
>>
>> Is
>>> there something out there now that could be imported and shaped up?
>>> At the other extreme, I'm envisioning busting out jflex/cup and
>>> doing a from-scratch implementation. I'm thinking there would be a
>>> lot of overlapping functionality with the front end of a compiler so
>>> should the two tools be considered together? Harmony doesn't have a
>>> start on it's own compiler yet, correct?
>>
>> We were planning to just use the eclipse compiler. No reason to
>> rewrite.
>>
>> I guess the best thing to do is do a quick write-up on how you might
>> go about this. Someone here must have some ideas to share too...
>>
>> geir
>>
>>> Jeremy
>>> On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
>>>> Ok - this isn't about the finer points of confusion surrounding
>>>> documentation....
>>>>
>>>> We need a javadoc tool for Harmony.
>>>>
>>>> The current conversation is a diversion from this, which I recall
>>>> was the original motivation behind the current generation of this
>>>> discussion.
>>>>
>>>> So, anyone interested? We need all the tooling actually...
>>>>
>>>> geir
>
>
--
IBM UK
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jeremy Huiskamp wrote:
[snip]
>
> What I could do is take the eclipse compiler and see what parts of it
> can be reused. I don't know anything about it so I won't offer any
> speculation now. Also, obviously eclipse has it's own javadoc
> functionality. Is that something that can be borrowed?
That's what I was about to suggest. Eclipse clearly groks javadoc. Why
not see how that does it?
>
> Assuming the easy case, that the tools are all there for poaching with
> minimal work, what would the proper action be? It could be stated that
> harmony will use the eclipse tools and you should go get them from
> eclipse if you want them (at least for the time being, until harmony
> gets to the point of being packaged up as a useable jdk). I gather
> that's the current status of the compiler. Or harmony could host the
> currently accepted binaries. Or the source code could be taken into
> svn, in which case there's the question of keeping in sync with the
> original tool. In all likelihood, it won't be that simple and harmony
> will have some of it's own modifications...
>
> Having asked so many questions, I'm now expecting to be told that
> whatever I feel like doing will be better than nothing :-p I'm off to
> see what I can find out about the eclipse toolset.
Whatever you feel like doing is better than nothing. Thanks for
volunteering :)
geir
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Jeremy Huiskamp <jh...@uoguelph.ca>.
Lovely, that's exactly the kind of pointers that'll help me :)
Another thing occurred to me this evening, and that is that xdoclet
must be extremely similar to javadoc. I will have a poke around with
that too and see if it isn't doable.
Jeremy
On 9-Feb-06, at 6:03 PM, Tim Ellison wrote:
> You may find it useful to take a look at the Eclipse Java AST APIs,
>
> http://help.eclipse.org/help31/index.jsp?topic=/
> org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/
> AST.html
> http://www-128.ibm.com/developerworks/opensource/library/os-ast/?
> ca=dgr-lnxw97ASTParser
> http://eclipsecon.org/2005/presentations/EclipseCON2005_Tutorial29.pdf
> ...
>
> specifically the javadoc node
>
> Regards,
> Tim
>
> Jeremy Huiskamp wrote:
>> First the disclaimer: I have zero experience with writing such
>> tools and
>> precious little with compilers. I'm just spewing what I think but if
>> there are accepted ways of doing these things, it'd be great for
>> anyone
>> to step in and school me. I'm here to learn, hopefully by
>> contributing :)
>>
>> What I'm thinking (and maybe this is dead obvious) is that there are
>> lots of high level tasks that javac and javadoc will have in common:
>> -understanding and parsing the syntax of the language itself
>> -the relevant parts of that are anything that you can javadoc: types,
>> fields, methods...
>> -the relation of classes in a package hierarchy, like when a method
>> takes an @arg of type java.lang.String, you've got to resolve that
>> and
>> produce a link to the String javadoc
>> -essentially having the ability to take a target dir and produce a
>> walkable data structure of all it's contents
>>
>> Of course, it's not a perfect match. Javadoc needs to treat javadoc
>> comments as different from other comments (not toss them) and it
>> doesn't
>> need to understand things at a level finer than, say, methods
>> (doesn't
>> need to know about if statements, loops, etc). But there's enough
>> there
>> that the javadoc front end could essentially be the javac frontend
>> with
>> the addition of handling the actual javadoc contents. Then, of
>> course,
>> the back end of the compiler spits out .class files while javadoc
>> spits
>> out html or whatever other format you need, but that's the reason for
>> the separation between front and back ends :)
>>
>> What I could do is take the eclipse compiler and see what parts of it
>> can be reused. I don't know anything about it so I won't offer any
>> speculation now. Also, obviously eclipse has it's own javadoc
>> functionality. Is that something that can be borrowed?
>>
>> Assuming the easy case, that the tools are all there for poaching
>> with
>> minimal work, what would the proper action be? It could be stated
>> that
>> harmony will use the eclipse tools and you should go get them from
>> eclipse if you want them (at least for the time being, until harmony
>> gets to the point of being packaged up as a useable jdk). I gather
>> that's the current status of the compiler. Or harmony could host the
>> currently accepted binaries. Or the source code could be taken into
>> svn, in which case there's the question of keeping in sync with the
>> original tool. In all likelihood, it won't be that simple and
>> harmony
>> will have some of it's own modifications...
>>
>> Having asked so many questions, I'm now expecting to be told that
>> whatever I feel like doing will be better than nothing :-p I'm
>> off to
>> see what I can find out about the eclipse toolset.
>>
>> Jeremy
>>
>> On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote:
>>
>>>
>>>
>>> Jeremy Huiskamp wrote:
>>>> What would be the suggested route for coming up with a javadoc
>>>> tool?
>>>
>>> Open up an editor, and start typing! :)
>>>
>>> Is
>>>> there something out there now that could be imported and shaped up?
>>>> At the other extreme, I'm envisioning busting out jflex/cup and
>>>> doing
>>>> a from-scratch implementation. I'm thinking there would be a
>>>> lot of
>>>> overlapping functionality with the front end of a compiler so
>>>> should
>>>> the two tools be considered together? Harmony doesn't have a start
>>>> on it's own compiler yet, correct?
>>>
>>> We were planning to just use the eclipse compiler. No reason to
>>> rewrite.
>>>
>>> I guess the best thing to do is do a quick write-up on how you might
>>> go about this. Someone here must have some ideas to share too...
>>>
>>> geir
>>>
>>>> Jeremy
>>>> On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
>>>>> Ok - this isn't about the finer points of confusion surrounding
>>>>> documentation....
>>>>>
>>>>> We need a javadoc tool for Harmony.
>>>>>
>>>>> The current conversation is a diversion from this, which I recall
>>>>> was the original motivation behind the current generation of this
>>>>> discussion.
>>>>>
>>>>> So, anyone interested? We need all the tooling actually...
>>>>>
>>>>> geir
>>
>>
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Tim Ellison <t....@gmail.com>.
You may find it useful to take a look at the Eclipse Java AST APIs,
http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/AST.html
http://www-128.ibm.com/developerworks/opensource/library/os-ast/?ca=dgr-lnxw97ASTParser
http://eclipsecon.org/2005/presentations/EclipseCON2005_Tutorial29.pdf
...
specifically the javadoc node
Regards,
Tim
Jeremy Huiskamp wrote:
> First the disclaimer: I have zero experience with writing such tools and
> precious little with compilers. I'm just spewing what I think but if
> there are accepted ways of doing these things, it'd be great for anyone
> to step in and school me. I'm here to learn, hopefully by contributing :)
>
> What I'm thinking (and maybe this is dead obvious) is that there are
> lots of high level tasks that javac and javadoc will have in common:
> -understanding and parsing the syntax of the language itself
> -the relevant parts of that are anything that you can javadoc: types,
> fields, methods...
> -the relation of classes in a package hierarchy, like when a method
> takes an @arg of type java.lang.String, you've got to resolve that and
> produce a link to the String javadoc
> -essentially having the ability to take a target dir and produce a
> walkable data structure of all it's contents
>
> Of course, it's not a perfect match. Javadoc needs to treat javadoc
> comments as different from other comments (not toss them) and it doesn't
> need to understand things at a level finer than, say, methods (doesn't
> need to know about if statements, loops, etc). But there's enough there
> that the javadoc front end could essentially be the javac frontend with
> the addition of handling the actual javadoc contents. Then, of course,
> the back end of the compiler spits out .class files while javadoc spits
> out html or whatever other format you need, but that's the reason for
> the separation between front and back ends :)
>
> What I could do is take the eclipse compiler and see what parts of it
> can be reused. I don't know anything about it so I won't offer any
> speculation now. Also, obviously eclipse has it's own javadoc
> functionality. Is that something that can be borrowed?
>
> Assuming the easy case, that the tools are all there for poaching with
> minimal work, what would the proper action be? It could be stated that
> harmony will use the eclipse tools and you should go get them from
> eclipse if you want them (at least for the time being, until harmony
> gets to the point of being packaged up as a useable jdk). I gather
> that's the current status of the compiler. Or harmony could host the
> currently accepted binaries. Or the source code could be taken into
> svn, in which case there's the question of keeping in sync with the
> original tool. In all likelihood, it won't be that simple and harmony
> will have some of it's own modifications...
>
> Having asked so many questions, I'm now expecting to be told that
> whatever I feel like doing will be better than nothing :-p I'm off to
> see what I can find out about the eclipse toolset.
>
> Jeremy
>
> On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote:
>
>>
>>
>> Jeremy Huiskamp wrote:
>>> What would be the suggested route for coming up with a javadoc tool?
>>
>> Open up an editor, and start typing! :)
>>
>> Is
>>> there something out there now that could be imported and shaped up?
>>> At the other extreme, I'm envisioning busting out jflex/cup and doing
>>> a from-scratch implementation. I'm thinking there would be a lot of
>>> overlapping functionality with the front end of a compiler so should
>>> the two tools be considered together? Harmony doesn't have a start
>>> on it's own compiler yet, correct?
>>
>> We were planning to just use the eclipse compiler. No reason to rewrite.
>>
>> I guess the best thing to do is do a quick write-up on how you might
>> go about this. Someone here must have some ideas to share too...
>>
>> geir
>>
>>> Jeremy
>>> On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
>>>> Ok - this isn't about the finer points of confusion surrounding
>>>> documentation....
>>>>
>>>> We need a javadoc tool for Harmony.
>>>>
>>>> The current conversation is a diversion from this, which I recall
>>>> was the original motivation behind the current generation of this
>>>> discussion.
>>>>
>>>> So, anyone interested? We need all the tooling actually...
>>>>
>>>> geir
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Jeremy Huiskamp <jh...@uoguelph.ca>.
First the disclaimer: I have zero experience with writing such tools
and precious little with compilers. I'm just spewing what I think
but if there are accepted ways of doing these things, it'd be great
for anyone to step in and school me. I'm here to learn, hopefully by
contributing :)
What I'm thinking (and maybe this is dead obvious) is that there are
lots of high level tasks that javac and javadoc will have in common:
-understanding and parsing the syntax of the language itself
-the relevant parts of that are anything that you can javadoc: types,
fields, methods...
-the relation of classes in a package hierarchy, like when a method
takes an @arg of type java.lang.String, you've got to resolve that
and produce a link to the String javadoc
-essentially having the ability to take a target dir and produce a
walkable data structure of all it's contents
Of course, it's not a perfect match. Javadoc needs to treat javadoc
comments as different from other comments (not toss them) and it
doesn't need to understand things at a level finer than, say, methods
(doesn't need to know about if statements, loops, etc). But there's
enough there that the javadoc front end could essentially be the
javac frontend with the addition of handling the actual javadoc
contents. Then, of course, the back end of the compiler spits
out .class files while javadoc spits out html or whatever other
format you need, but that's the reason for the separation between
front and back ends :)
What I could do is take the eclipse compiler and see what parts of it
can be reused. I don't know anything about it so I won't offer any
speculation now. Also, obviously eclipse has it's own javadoc
functionality. Is that something that can be borrowed?
Assuming the easy case, that the tools are all there for poaching
with minimal work, what would the proper action be? It could be
stated that harmony will use the eclipse tools and you should go get
them from eclipse if you want them (at least for the time being,
until harmony gets to the point of being packaged up as a useable
jdk). I gather that's the current status of the compiler. Or
harmony could host the currently accepted binaries. Or the source
code could be taken into svn, in which case there's the question of
keeping in sync with the original tool. In all likelihood, it won't
be that simple and harmony will have some of it's own modifications...
Having asked so many questions, I'm now expecting to be told that
whatever I feel like doing will be better than nothing :-p I'm off
to see what I can find out about the eclipse toolset.
Jeremy
On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote:
>
>
> Jeremy Huiskamp wrote:
>> What would be the suggested route for coming up with a javadoc tool?
>
> Open up an editor, and start typing! :)
>
> Is
>> there something out there now that could be imported and shaped
>> up? At the other extreme, I'm envisioning busting out jflex/cup
>> and doing a from-scratch implementation. I'm thinking there would
>> be a lot of overlapping functionality with the front end of a
>> compiler so should the two tools be considered together? Harmony
>> doesn't have a start on it's own compiler yet, correct?
>
> We were planning to just use the eclipse compiler. No reason to
> rewrite.
>
> I guess the best thing to do is do a quick write-up on how you
> might go about this. Someone here must have some ideas to share
> too...
>
> geir
>
>> Jeremy
>> On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
>>> Ok - this isn't about the finer points of confusion surrounding
>>> documentation....
>>>
>>> We need a javadoc tool for Harmony.
>>>
>>> The current conversation is a diversion from this, which I recall
>>> was the original motivation behind the current generation of this
>>> discussion.
>>>
>>> So, anyone interested? We need all the tooling actually...
>>>
>>> geir
Re: [tools] Javadoc! Javadoc! Javadoc! (the tool, not the debate...)
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jeremy Huiskamp wrote:
> What would be the suggested route for coming up with a javadoc tool?
Open up an editor, and start typing! :)
Is
> there something out there now that could be imported and shaped up? At
> the other extreme, I'm envisioning busting out jflex/cup and doing a
> from-scratch implementation. I'm thinking there would be a lot of
> overlapping functionality with the front end of a compiler so should the
> two tools be considered together? Harmony doesn't have a start on it's
> own compiler yet, correct?
We were planning to just use the eclipse compiler. No reason to rewrite.
I guess the best thing to do is do a quick write-up on how you might go
about this. Someone here must have some ideas to share too...
geir
>
> Jeremy
>
> On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
>
>> Ok - this isn't about the finer points of confusion surrounding
>> documentation....
>>
>> We need a javadoc tool for Harmony.
>>
>> The current conversation is a diversion from this, which I recall was
>> the original motivation behind the current generation of this discussion.
>>
>> So, anyone interested? We need all the tooling actually...
>>
>> geir
>
>