As most of you are aware, most of the CXF website is generated from content
hosted in Confluence. That really works well. For the past year or so,
we've used a process from my crontab on p.a.o to generate the site from the
confluence content. Again, hasn't been an issue and it works fairly well.
However, infrastructure wants projects to really start the migration to using
svnpubsub for deploying the website instead of the current rsync based
approach that we are using. The good news is that the process we have from
my crontab can already handle that, we'll just need to move it from my crontab
to have buildbot run it. That's easy and not an issue. However, there are
2 issues:
1) Benson has started working on getting maven to generate some site content
as well, specifically for the plugins. I'm not TOO concerned about that.
When run, with svnpubsub, the person running it could checkout the site, run
the command, do and svn add or whatever, and commit. A little more involved,
but nothing major. (and similar to what is done in other places anyway).
2) The MAIN issue we have with CXF right now is the javadocs. We currently
house ALL the javadocs for ALL the past versions of CXF. That's about 3.2 GB
of space right now, and grows every release. If someone had to svn checkout
the whole site (for example, to run Benson's maven thing above or to add new
javadoc or similar), that's a LOT of bandwidth, a lot of drive space, etc....
There are a couple of options and like people's thoughts:
1) Keep all the javadoc in the svn for the site like it is now. Ignore the
bandwidth issue as most people won't need to do that anyway.
2) Keep JUST the latest javadoc - maybe latest on each of the supported
branches.
3) Move the javadoc off the main site and use an .htaccess redirect to point
off to there. I talked to Joe (infrastructure) and he suggested a CXF zone
where we could have our own tomcat running or something to host all the
javadoc.
Anyway, I'd like peoples thoughts on this. Even additional ideas. I'm
kind of leaning toward 2, but 3 would be OK as well.
Moving to svnpubsub will have an advantage of quicker turnaround of changes.
If we need to publish a new page, we can make the change in confluence, any
committer can checkout the site and run the command and commit, and the page
would be live in seconds. Currently it's about 1-2 hours.
--
Daniel Kulp
dk...@apache.org -
http://dankulp.com/blogTalend Community Coder -
http://coders.talend.com
