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/blog Talend Community Coder - http://coders.talend.com
