Perhaps the account where jenkins runs has a ssh key. Then we could
allow this key on the server. I think infra could do such a thing in
their settings.xml.
Christian
Am 17.06.2011 15:23, schrieb Guillaume Nodet:
On Fri, Jun 17, 2011 at 14:39, Jamie G.<[email protected]> wrote:
Good morning all,
It was really nice getting to put voices to the names here on IRC
yesterday. I think having these community conference calls are a great
way to bring our global team together :)
Jean-Baptiste, the meeting notes look good. I really like the idea of
having these calls regularly every 2 or 3 months.
As to scalate...
As a mechanism to produce the manuals I'm fine with its usage.
As a mechanism to produce our website I've had several issues, and
quite frankly just do my best to get past them with copious amounts of
help over IRC from community members. To be honest, updating a wiki or
scalate site requires the contributor to learn some amount of a
framework - wikis being common lowers the bar in general while scalate
requires something of an investment of time (not that its huge). I
think what slows or stops a new user from jumping into altering the
website (contributing a patch) is that hitting scalate for the first
time it may appear to be more daunting than it is... it definitely is
more work to do, requiring more touch time to get things all together
(just my experience). Perhaps the solution is to create a tutorial on
how to update the site, that explicitly shows a user where to get the
code, how to build/test it, and where to create the JIRA& attach
their patch. Another tutorial should also be made to explain how the
karaf site it put together; I know that during each release I spend
far too much time trying to find all the places I need to update or
append to in the source, vs the old just add page where I want it on
the wiki site (perhaps there is a better way I am unfamiliar with, if
there is please let me know).
Yeah, you're right. We should have a web page that can be used as a
tutorial for updating the web site.
Setting up a nightly CI build to deploy the website nightly would help
keep the site more up to date with recent commits. I have to agree
with Christian that updates to the website have been slow getting into
production. I know from my experience setting up to update our webpage
took a bit of messing around, so not having to do that would be a
boost to productivity. This being said do we have a username/password
combo that we can leave on the CI box? The current setup requires
committer credentials to upload/deploy the site, perhaps infra has an
account such as this already created though - we should find out from
them if something like that is available.
Good point. As a work around, a small cron job would do the trick,
but CI would be way better if possible.
Cheers,
Jamie
On Fri, Jun 17, 2011 at 9:12 AM, Guillaume Nodet<[email protected]> wrote:
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<[email protected]> 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<[email protected]> wrote:
On 17 June 2011 12:16, Christian Schneider<[email protected]> 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: [email protected]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration and Messaging
--
James
-------
FuseSource
Email: [email protected]
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
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
