Tim Ellison wrote:
Geir Magnusson Jr wrote:
Tim Ellison wrote:
Loenko, Mikhail Y wrote:
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 u
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 compatib
Hi,
On Fri, 2006-01-13 at 10:38 +, Tim Ellison wrote:
> Perhaps our friends involved with Classpath can give us an insight as to
> whether they regret writing JavaDoc, or whether they see it as a
> valuable part of the effort (assuming that they have written all the doc!).
You can
Geir Magnusson Jr wrote:
>
> Tim Ellison wrote:
>
>> Loenko, Mikhail Y wrote:
>> 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. Wh
> "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 reas
implementation Java(tm) --
and that is to pass the JCK.
Moreover, we will need a
number of native English speakers 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 d
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 al
>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 where our skill
e first :).
There is only one way that you can call an implementation Java(tm) --
and that is to pass the JCK.
> Moreover, we will need a
> number of native English speakers who will volunteer to write the docs
> for us.
I sense that there is an underlying reason for the objection to writing
J
he methods that act exactly as specified?
Thanks,
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
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
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
identical to the specification. Is the
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 (
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/me
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 specific
semantics and mislead
> people who read our docs rather then official spec.
>
> Thanks,
> Mikhail Loenko
> Intel Middleware Products Division
>
>
>>-Original Message-
>>From: Tim Ellison [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, January 10, 200
ld unintentionally change semantics and mislead
people who read our 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.ap
our 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: [R
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-pa
19 matches
Mail list logo
