Geir Magnusson Jr wrote:
Tim Ellison wrote:
Loenko, Mikhail Y wrote:
snip
I agree it is good practice to document the implementation of some
non-API code for developers.
Some? why not all?
... because by definition the non-API code does not require
documentation for the user. Where
Hi Loenko.
On Fri, 2006-01-13 at 15:32 +0300, Loenko, Mikhail Y wrote:
I think Classpath is a little bit different story. It is not a Java(tm)
so a developer who writes for Classpath has to validate with Classpath
docs whether his code is going to work.
No, the goal is to be a free compatible
Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Loenko, Mikhail Y wrote:
snip
I agree it is good practice to document the implementation of some
non-API code for developers.
Some? why not all?
... because by definition the non-API code does not require
documentation for
who will volunteer to write the docs
for us.
I sense that there is an underlying reason for the objection to writing
JavaDoc ;-) Do you really *want* URLs to Sun's website, or do you think
that writing the doc will be too much effort, or ... ? How about
writing it in multiple languages if that's
Loenko, Mikhail Y wrote:
Well, I'll try to summarize what we have
There are three types of methods:
1. Methods that are part of the API, they are specified, they follow the
Sun's spec and we have nothing to add.
2. Methods that are part of the API and we have something to add (ex.:
the spec
Mikhail == Loenko, Mikhail Y [EMAIL PROTECTED] writes:
Mikhail I think Classpath is a little bit different story. It is not
Mikhail a Java(tm) so a developer who writes for Classpath has to
Mikhail validate with Classpath docs whether his code is going to
Mikhail work.
The real reason we write
,
Mikhail Loenko
Intel Middleware Products Division
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 7:21 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Writing JavaDoc
Sorry, I misunderstood. So your option #3 is not copying the JavaDoc
Loenko, Mikhail Y wrote:
Thanks for accepting the contribution
There's a bit of things that come out of this, like the
com.intel.drl.spec_ref javadoc tag that we should convert, and such.
What would be the best for those javadocs? We can have 3 possible
options:
1. Copy-paste from the
docs rather then official spec.
Thanks,
Mikhail Loenko
Intel Middleware Products Division
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 4:26 PM
To: harmony-dev@incubator.apache.org
Subject: Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE
Middleware Products Division
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 4:26 PM
To: harmony-dev@incubator.apache.org
Subject: Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE] Accept
JIRA contribution HARMONY-16
(Intel's contrib
Zsejki Sorin Miklós wrote:
I have absolutely no experience with such things, but I'm wondering how
was this done with Tomcat, for example. They have the servlet API built
from their source code, and the javadoc seems to be word by word
identical to the specification. Is the servlet
Tim Ellison wrote:
Sorry, I misunderstood. So your option #3 is not copying the JavaDoc
and redistributing it, but documenting links to the Sun site.
IMHO, creating a set of JavaDoc that contains links to Sun's existing
JavaDoc is unlikely to appeal to most people -- the package/type/method
inline
-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 5:26 AM
To: harmony-dev@incubator.apache.org
Subject: Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE]
Accept JIRA contribution HARMONY-16 (Intel's contrib of
security code
Stefano Mazzocchi wrote:
Dalibor Topic wrote:
Zsejki Sorin Miklós wrote:
I have absolutely no experience with such things, but I'm wondering how
was this done with Tomcat, for example. They have the servlet API built
from their source code, and the javadoc seems to be word by word
14 matches
Mail list logo
