Since Benson outed this on the dev@ws list, I might as well mention it here....
As some of you know, Apache INFRA is not exactly happy with the current autoexport solution that is being used to export the CXF site and docs to the static HTML files that are served from the live site. There are a lot of issues with it, some of which I do actually consider valid. At some point this year, they do plan on turning off the autoexport capabilities of our Confluence install. By that point the projects hosting their sites from Confluence need to have found a different solution. (and, of course, they recommend their new markdown based CMS, which I'm not happy with.) A couple weeks ago, I did some work to write an external program that uses the Confluence SOAP interface to do the export. (if anyone can use a SOAP interface, it should be us.... ;-) You may have seen the commits in the cxf/web dir related to that. Run from a cron job on p.a.o, it periodically checks for changes and will export the appropriate changes to the live site. It's actually a lot smarter than autoexport (example: it knows about pages like "Navigation" that require a full rebuild) as well as generates much better HTML (it's HTML4/transitional compliant according to the w3c validator). This new program has been "live" for two weeks now and other than a few minor issues, no one has really noticed. The site has "just worked". Actually, with the new program, I was able to add the "Add Comment" (but in autoexport prevented that from working) link to the bottom so it's even better than before. Anyway, from a normal "workflow" standpoint, nothing has changed. You can click on the "edit' link, edit the pages, etc.... It will eventually sync to the live site just like before. However, I thought I'd mention that the templates and such configured in the autoexport plugin in confluence are no longer the "real" versions being used. See the cxf/web stuff in svn for that. Thus, when INFRA turns off autoexport, we'll be "ready" with a solution. :-) Longer term (like in 2012 sometime), INFRA also plans on requiring the use of svnpubsub for the sites. Basically, that means the site will need to be checked into svn. The normal rsyncs (and mvn site:deploy things to p.a.o) won't work. This solution should be able to support that as well. I plan to add svn support to the exporter so the stuff it generates can be added automatically into svn and committed. At that point, it would be moved from a cron job to a build on buildbot (likely, jenkins/hudson MAYBE). What THAT will allow is immediate updates to the site. You'd be able to edit the confluence content and either manually run the exporter or click the "build now" button on buildbot and the site would be live in seconds. That's mostly useful for the release manager (me) when updating the release notes and download links. :-) Like I said, that all is a little furthur out. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
