On Tue, 8 May 2001, Ceki [iso-8859-1] G�lc� wrote:
>
> Agreed. Mandating that the docs contained in the distribution and the
> docs available on the jakarta web server match exactly is too
> restrictive.
+1 -- it should be up to the project. I've got projects that do it both
ways.
> However, allowing the user to browse the documentation
> locally from the files contained within the distribution is a nice
> feature. Wouldn't you agree?
>
Also +1. One approach is to include a webapp of static HTML files that
the user can drop into their container (if they have one), or use as a
static directory of files (if they don't).
>
> >Ceki's description of log4j's doc dance works, but makes altering www
> >docs post-release tricky. I think docs are likely to be a bit behind the
> >curve, particularly for smaller projects.
>
> True.
>
> >So, the current system of checking out www docs from cvs makes sense
> - it allows doc amends for >last release to be tracked.
>
> I think no one is contesting that tracking source files using CVS is a
> good idea. However, the CVS update operation is one way of copying the
> latest version of doc files to the jakarta web server. It is certainly
> not the only way. Reading your comments below, I think that we are
> actually in total agreement.
>
I'm not a fan of the way jakarta-site2 makes you check in the generated
HTML either. I'd rather see the cycle work like this:
Local machine:
- Edit XML (or whatever) sources
- Generate and test
- Check in XML sources
Daedalus:
- Check out XML sources
- Generate in place
Formerly, we didn't have a useful Java2 environment on the server
(locus). Now we do -- let's use it :-)
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
