----- Original Message -----
From: "Rodney Waldhoff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 18, 2001 2:01 AM
Subject: Re: cvs commit: JavaDocs
> >UGH. Why commit the JavaDoc when it's just generated from the source
code,
> >and there are multiple build targets for creating and dealing
> >with it?
>
> For the same reason we check the .html documents in /docs in, even though
> they are generated from /xdocs/*.xml--because that's the way you get it on
> the live site. That's the way all the rest of the
> jakarata.apache.org/commons site is generated/published (maybe with the
> exception of the cactus docs, which had a legacy documetation
> generation/publication system).
Actually, I have never paid much attention to understanding why the html was
checked in. Could you explain it to me in a few words because I don't see
the point ? The only advantage I could see is that you could work on the xml
docs for the *next* release, thus describing features that are not in the
current release, so you don't want to publish these docs yet. However, you
may want to publish parts of them (like when you improved a tutorial for
exemple). So you would generate the xdocs and only copy what you want to the
HTML doc directory. Also, you would be able to make changes directly to the
HTML (with the risk of forgetting to report the change in your .xml docs).
Is that it ?
If not, I would still like to know what is the standard practice for what I
described ? I could manage it with only the .xml docs on Cactus but
sometimes it is a bit a pain (but it is definitely simpler but for the
moment I have been the only one to commit the docs so maybe it gets more
difficult to manage when there are several persons working on the docs at
the same time?).
>
> I didn't set up the system. Feel free to improve it. I'm not a huge fan
> either, but I do see some advantages.
thanks
-Vincent
