+1,
and we can also add a maven goal execution to update website/manual.
Regards
JB
On 06/17/2011 01:35 PM, Guillaume Nodet wrote:
Yeah, I think everything is already setup correctly, we just need to
add the nightly builds to the CI system.
On Fri, Jun 17, 2011 at 13: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
