<!--#include file="./source.inc"-->The inclusion seems to be broken currently.
javadoc -classpath /usr/java/classes:/homes/sep/matt/jest -sourcepath /usr/java/src:/homes/sep/matt/jest -d /homes/sep/matt/jest/jdocs/api java.io java.lang ... rsf.vector rsf.utilThe last list states all the packages for which I want to create a javadoc page. The classpath and the sourcepath let javadoc know where to look for these packages. The "-d" argument states where to put the generated html files.
I believe the class files have to be unzipped and the java source files have to available. To create javadoc pages for the official java API you need to get the java source code, unzip the class files, and include them in the javadoc invocation as shown above. I would like to know how to use zipped classes and to be independent of the source code.
The directory where I install the html pages needs some special care. I need to include the source.inc file for the source inclusion and I need to make a link to the images files for the various gifs that adorn the pages.
I use a combination of a makerule and a simple perl script to remake all javadoc documents from scratch. Given the class- and source path the script figures out all the packages that are included. Currently, the script searches for class files (suffix: .class) but I wonder if I should look for java source files (suffix: .java) instead. A simple make rule,
make javadocGlobal, generates the list of all packages within subdirectories of the original path directory and creates javadoc html pages for all of them. It would be nice if we could keep the javadoc pages separate by package group (api, jag, book, etc) like we keep the corresponding java and class files.
packages.html, when invoked. It would be nice to have new packages intelligently added to these overview documents without overwriting the already javadoc html. It seems that the lass hierarchy file is correctly updated rather than replaced.
It is difficult to remove javadoc generated html files when the underlying software becomes obsolete. I plan to remove all javadoc files from time to time.Afterwards I will reinstall the javadoc files from scratch. It would be nice to surgically remove, enhance, or replace individual packages.
Removing outdated .html files is difficult. Another problem with javadoc in general is removing documentation for a package. If you remove some classes from a package, and then redocument it with javadoc, I don't think that it removes the vestigial .html files, and I wonder if it removes the class from the class hierarchy.
Javadoc requires that we mix our javadoc files with the official API javadoc files so that they can crossreference. According to our Guru book, we need to have the API javadoc files mixed with our own javadoc files. You can either put everything all together or have many copies of the API files. (maybe we could do some fancy linking).
Anyhoo, it's much better to have a central packages.html file instead of having to remember the name of the package you're looking for and typing it in.
The page isn't perfect, but click on Java in the lower left on your web page. Then click on Jag underneath Class Documentation near the bottom.