> From: Aaron M. Renn [mailto:[EMAIL PROTECTED]]
>
> John Keiser ([EMAIL PROTECTED]) wrote:
> > (Oh, that's the other problem. There's no getPackageDoc() in
> ClassDoc, and
> > no getRootDoc in PackageDoc.)
>
> Feel free to fix that.
>
The problem is not in your code, it's in the spec, sorry if there was
confusion there. I can fix it, but then apps using those methods would lose
out when porting to other VM's (which is bad, as you correctly point out
below).
> > I am going to write out an architecture that will allow Doclets to be
> > written a little easier that allows this sort of thing, but I
> want to make
> > sure I'm not reinventing the wheel here.
>
> I would stick to the standard JavaDoc architecture. After all, we want
> to make sure that other people's doclets can work with our code. Since
> this isn't a core Java package, we can create our own extensions, though
> they must be upwardly compatible with the existing ones. However,
> simply modifying the javadoc api package won't accomplish much because
> the driver program won't use our extensions, requiring that a driver
> prog be written first, which I think is backwards.
>
> In some of these obscure situations, I'd run a test with Sun's javadoc
> tool to see what comes out and emulate that behavior. You could also
> find another doclet someone has released under a free software license
> and look at what they did. As you say, we definitely want to avoid
> reinventing the wheel.
>
The architecture I'm talking about is upwards compatible--i.e. you can use
standard Doclets against our Doclet API, or you can write Super-Gnu-Doclets
and plug in our classes (gnu.javadoc.* or something) and everything will
even work unmodified on Sun's VM. It is built *on top of* the Doclet API,
not into it. No need to duplicate or break existing functionality, just add
to it.
What I working on is really a set of helper classes, a superstructure, for
building a Doclet. It will make it that much easier to create new Doclets,
taking out a lot of duplicate code.
I guess that answers my question though. I was mainly wondering if the
existing JavaDoc API actually had the stuff I needed but I was just unable
to find it. The verdict is that there is no nice, clean way to get a full
list of the packages that need generating, and that there is no function in
PackageDoc or ClassDoc to get the containing root or package (respectively)?
If not, I will build these helper classes to take care of that sort of thing
without changing the com.sun.* API.
If anyone has implemented a more-than-trivial doclet before, speak up!
--John
