How about creating a jakarta-commons-site for the generated html.
It solves the commit mail problem => separate non-mandatory list for html commit mails.
It meets the requirements from the infrastructure team and we have a place to store the generated javadocs/userguides from official release builds.


Generated:
/jakarta-commons-site/index.html               => commons homepage
/jakarta-commons-site/component/index.html     => current component overview
/jakarta-commons-site/component/userguide/     => current component userguide
/jakarta-commons-site/component/apidocs/       => current API (cvs head)
/jakarta-commons-site/component/1.0/           => version 1.0
/jakarta-commons-site/component/1.0/apidocs/
/jakarta-commons-site/component/1.0/userguide/
/jakarta-commons-site/sandbox/component/*      => sandbox component

Source:
/jakarta-commons/xdocs/*                       => commons site source
/jakarta-commons/component/xdocs/              => component site source
/jakarta-commons-sandbox/component/xdocs/      => sandbox component

With the commit mail problem solved the only issue is disk space but that is an infrastructure issue. If CVS backup/restore is the policy then why not.

-- Dirk


Noel J. Bergman wrote:


First, we need to settle the issue of what goes in CVS. If "all generated HTML" is the answer, we need to get all of the maven-
generated HTML committed (many megs of redundant content, many
redundant commit messages IMHO).


What makes that any different from any Anakia or Forrest built site?

--- Noel




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to