BTW we found on the Scalate project we wanted 2 continuous website builds; the current production site branch (i.e. docs for the last major release); so the thing to make http://karaf.apache.org/. Then a continuous build of the new version (trunk); http://karaf.apache.org/versions/3.0-SNAPSHOT (or whatever).
Then folks can update the current production website in one branch; or update what will be the next major release (which may be months away); but folks can still view/read the docs for trunk on the website if they want. Also when a release is made, the docs are deployed to a fixed area: http://karaf.apache.org/versions/2.2.3/ or whatever. Then you've just gotta maintain the http://karaf.apache.org/versions/index.html page to link to the various available versions etc. On 17 June 2011 12:28, James Strachan <ja...@fusesource.com> wrote: > On 17 June 2011 12:16, Christian Schneider <ch...@die-schneider.net> wrote: >> Am 17.06.2011 12:53, schrieb Guillaume Nodet: >>> >>> Over the last 5 years, I've rarely seen people contributing a lot to >>> the doc without being or becoming committers. >>> I don't want to change a technical decision based on the fact that >>> people *might* need something, but rather what people actually need. >>> You are a committer, so you can access / modify the documentation >>> without any problems. So what are your real problems with the current >>> solution ? We can easily set up nightly uploads or even an hourly >>> cron job (though given the change rate, i think a nightly one should >>> be sufficient). If you need an editor, you always find some software >>> I think such as >>> http://www.labnol.org/software/wysiwyg-wiki-editor/18062/ though I >>> tend to use the "mvn jetty:run" which works quite well as you can see >>> your changes immediately. >> >> For me as a committer now it is ok. I also do not have problems with editing >> wiki syntax text files by hand. After reading all the comments I think that >> the solution is good for now. I just fear that we might not really attract >> people to help. But you are right people who just work on the documentation >> are rare anyway. >> >> It would be great if we could establish an automatic update of the website >> for trunk and the current production branch. Ideal would be a script like in >> jenkins that only fires when there are real changes then it can be run in >> very short cycles. > > Its really no different from a regular continuous integration build > really; building & deploying the website is just a different mvn > plugin so its like doing snapshot deploy builds. > > >> Btw. How about using jenkins to update the website? The >> update just has to be callable from maven and we have to authenticate in >> some way. Jenkins would also allow to track when and why updates have beem >> done. > > We've been doing this on the Scalate project for a while btw; its just > a matter of setting up a jenkins build in the right branch and using a > profile in the maven build to do the deploy of the website project (as > you probably don't want other builds deploying the website by > default). > > This kinda thing does the trick in the website pom... > > <plugin> > <groupId>org.fusesource.scalate</groupId> > <artifactId>maven-scalate-plugin</artifactId> > <version>${project.version}</version> > <configuration> > > <remoteServerId>people.apache.org</remoteServerId> > > <!-- server stuff here - scp or dav or whatnot... --> > <!-- TODO fixme - i just made this up .... ---> > > <remoteServerUrl>scp:people.apache.org:/www/karaf.apache.org/versions/${project.version}</remoteServerUrl> > </configuration> > <executions> > <execution> > <id>sitegen</id> > <goals> > <goal>sitegen</goal> > </goals> > <phase>package</phase> > </execution> > <execution> > <id>deploy</id> > <goals> > <goal>deploy</goal> > </goals> > <phase>deploy</phase> > </execution> > </executions> > </plugin> > > -- > James > ------- > FuseSource > Email: ja...@fusesource.com > Web: http://fusesource.com > Twitter: jstrachan, fusenews > Blog: http://macstrac.blogspot.com/ > > Open Source Integration and Messaging > -- James ------- FuseSource Email: ja...@fusesource.com Web: http://fusesource.com Twitter: jstrachan, fusenews Blog: http://macstrac.blogspot.com/ Open Source Integration and Messaging
