jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: move site outside of maven?
Date Mon, 20 Mar 2006 17:50:25 GMT

On 3/20/06, Fabrizio Giustina <fgiust@apache.org> wrote:
> All those reports are simply not meant to be checked into a scm
> repository... I know that the Apache guidelines tells to "not to
> modify files directly in the site directory, but check them into
> subversion instead" but I don't think that such recommendation could
> apply to files that are totally generated from other sources.

I pretty much agree with you, but I do see a point in the guidelines
as well. The more complex the site publishing process is, the easier
it is for it to get broken due to either a bug or a user error. For
example it would be easy for me to forget the LANG=en setting from a
maven site:sshdeploy command, which would result in all the reports
being localized to Finnish until someone notices to fix the problem.
:-) I could also have some transient files laying around that might
accidentally get published on the web site even though no record of
them is ever stored in version control.

One way to make "direct" publishing approach the reliability of going
through subversion would be to have the site generation performed on a
server with no manual intervention. For example a nightly script could
automatically checkout the latest source tree, generate the site, and
deploy it. I've even seen setups where a subversion post-commit script
generates and deploys the site.

I don't suppose the ASF infrastructure will support such a feature
(with Maven/Forrest/Anakia/etc.) in near future, so the best way to do
something like that would probably be to apply for a
jackrabbit.zones.apache.org and set up a site build script there.

If bypassing subversion is OK for site publishing, then we could
simply copy the generated site files to the public site location.
Otherwise we could have the site build script prepare a subversion
changeset that could simply be committed once the staging site has
been reviewed. This could possibly be a "best of both worlds" option.

PS. An old thread about the same issue:


Jukka Zitting

Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
View raw message