You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2012/01/24 18:49:50 UTC
CXF website, svnpubsub, javadocs, etc....
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF website, svnpubsub, javadocs, etc....
Posted by Eric Johnson <em...@fusesource.com>.
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 returns.
Eric Johnson
Principle Technical Writer | FuseSource Corp.
emjohnson@fusesource.com | fusesource.com
office: (781) 280-4174
skype: finnmccumial | twitter: @finnmccumial
blog: http://documentingit.blogspot.com/
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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: CXF website, svnpubsub, javadocs, etc....
Posted by Daniel Kulp <dk...@apache.org>.
Since the only two people that responded was supportive of option #2, I'll go
ahead and pursue that. Hopefully we can get that setup later this week.
Thanks!
Dan
On Tuesday, January 24, 2012 12:49:50 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF website, svnpubsub, javadocs, etc....
Posted by Christian Schneider <ch...@die-schneider.net>.
+1
for 2)
In Eclipse I always get the sources and so also javadoc from maven so I
only use javadoc on the web when I want to use google to search
something and then the trunk or the latest release is good enough.
Christian
Am 24.01.2012 18:49, schrieb Daniel Kulp:
> 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.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com