Mark Roth wrote:
Unfortunately, the answer is no, even though it seems rather silly. The
reason is that the specifications themselves have an auto-generated copy
of the javadocs in PDF format, and the assertion list for the TCK is
generated, in part, based on the javadoc tags. Converting an in
Hi Mark,
Mark Thomas wrote:
Mark,
One final question. The javadoc bugs I was looking at were of the following
types:
- @returns used rather than @return
- @seealso used rather than @see
- etc
Yuck. :) It's unfortunate we didn't catch those earlier. I'm
definitely interested in a list of a
Mark,
One final question. The javadoc bugs I was looking at were of the following
types:
- @returns used rather than @return
- @seealso used rather than @see
- etc
Is it permitted to make changes to fix these? There were no changes to the
actual text of the javadoc.
Thanks,
Mark
On Wednes
Hi Yoav,
Shapira, Yoav wrote:
Howdy,
Thanks for the clarification Mark, and for beating me to the question
Tim ;)
No problem!
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
-
To unsubscribe, e-m
Hi Tim,
Tim Funk wrote:
Does this mean that any bug submitted with a criticism (or patch)
against jakarta-servletapi-* can be marked as WONTFIX with a advisory
for the requestor to notify [EMAIL PROTECTED] or
[EMAIL PROTECTED] ? (I know there is at least one bug in
this category)
If the bug fi
: Re: Important information about jakarta-servletapi-*
>
>Does this mean that any bug submitted with a criticism (or patch)
against
>jakarta-servletapi-* can be marked as WONTFIX with a advisory for the
>requestor to notify [EMAIL PROTECTED] or
>[EMAIL PROTECTED] ? (I know there is at l
Does this mean that any bug submitted with a criticism (or patch) against
jakarta-servletapi-* can be marked as WONTFIX with a advisory for the
requestor to notify [EMAIL PROTECTED] or
[EMAIL PROTECTED] ? (I know there is at least one bug in this
category)
-Tim
Mark Roth wrote:
Hi everyone,
Hi everyone,
I've seen a few requests to fix items in the jakarta-servletapi-*
workspaces and wanted to clear up any confusion there might be.
Changes to examples in these workspaces are fine.
However, ANY changes to the core APIs (including even simple javadocs
changes) CANNOT be done outside
