[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Cp-tools-discuss] Gjdoc sample output
From: |
Julian Scheid |
Subject: |
[Cp-tools-discuss] Gjdoc sample output |
Date: |
Mon, 10 Mar 2003 01:20:44 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126 |
I generate the full Classpath API from time to time for testing
purposes and thought I'd put it on the Web until the official
Classpath API docs are updated.
Find it here: http://217.160.129.185:6565/classpath-api/index.html
It is password protected to keep the bots out - username is 'cp',
password the same. This is the full documentation for Classpath,
updated yesterday from CVS.
You may want to check above page sometimes when you see CVS commits
for Gjdoc, I will try to keep it in sync with my changes.
Notes:
- Package Tree generation turns out to be awfully slow for the full
Classpath tree, actually it's unbearable. Until I have optimized the
process, I have disabled their generation. Under above link you will
find trees for some packages, but not all, I stopped the process at
some time.
- The date format in the footer is German. This is already fixed, the
date will now always be US english regardless of what locale Gjdoc
is run in. (I plan to add i18n support in the long term, though.)
- Missing package descriptions result in ugly blanks on the front page.
- Some @see links do not work properly.
- No, it's not very useful to have a list of all known direct subclasses
of java.lang.Object ;)
- Misplaced HTML tags in some Classpath comments can lead to undesired
results. This is most obvious in java.applet, where an occurrence of
the string "<applet>" in a comment leads to a bogus applet popping
up on the documentation pages. I suppose you don't mind if I fix these
problems as I encounter them. (I think I do have write access to
Classpath.)
The worst problem, which you can't see in above pages, now turns out
to be performance. The changes I did in the last release affected
performance for large source trees far more severe than I had thought.
I think pre-computing the heritage information in the doclet and storing
it as XML data will help a lot. XSLT doesn't seem to be so fast at
recursive operations.
Julian
- [Cp-tools-discuss] Gjdoc sample output,
Julian Scheid <=