Hi Guillaume, this might be a good place to put in the wiki, as long as it isn't disabled. That way we can keep our "non-Versioned" documentation from beeing updated through a build process (kind of a overhead) just embed this stuff like the "Roadmap" in the Main Page.
Just my 2 cents :-) Achim 2011/6/17 Guillaume Nodet <gno...@gmail.com>: > The setup is slightly different as we have two web sites, one for the > manuals which is versioned and one for the main web site which isn't. > Things such as committers list, board reports and such aren't really > tied to a release schedule imho. > > On Fri, Jun 17, 2011 at 13:38, 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 >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
