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
