cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <>
Subject Re: CXF website, svnpubsub, javadocs, etc....
Date Tue, 24 Jan 2012 18:12:55 GMT
I think 2) is sufficient. Most people will be looking for the Javadocs for the latest version
of the one of the supported releases. I'm all for more information versus less information,
but keeping every version of the Javadocs on the Web site starts getting to the point of diminishing

Eric Johnson
Principle Technical Writer | FuseSource Corp. |
office: (781) 280-4174
skype: finnmccumial | twitter: @finnmccumial

On Jan 24, 2012, at 12:49 PM, Daniel Kulp wrote:

> 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
> -
> Talend Community Coder -

View raw message