would be quite useful if the nightly builds really work! Definitely +1 for the hudson setup
On Fri, Jun 17, 2011 at 1:38 PM, James Strachan <ja...@fusesource.com> wrote: > 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 >
