Vincent,
As far as I know the html is checked in so that it can be checked out
onto the jakarta site. So the developer sets up his/her machine, and
then generates and checks in docs, and then logs onto the website box
and does a 'cvs update', which just pulls out the html.
Scott Sanders
> >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
