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]