Mailing-List: contact dev-help@servicemix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@servicemix.apache.org
Received-SPF: pass (nike.apache.org: domain of gert.vanthienen@gmail.com
 designates 209.85.210.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <C420B6F9-A032-477F-A2FB-D9621A79F41B@apache.org>
References: 
 <CACAPQZ5nTAr5Cz+=VPmXdwGjjQkxcgOY4gLw1xToRk=Yd9djNA@mail.gmail.com>
	<CAGB5yNkwcPa4zVDqa5LR5c=gvM750u7kZA=zSYu_YOC0yfoBjQ@mail.gmail.com>
	<C420B6F9-A032-477F-A2FB-D9621A79F41B@apache.org>
Date: Tue, 4 Sep 2012 16:37:39 +0200
Message-ID: 
 <CACAPQZ6TOwxHw3BR92bTLf+JqpLCOH0zJOOOLQZ+940b7ps2QA@mail.gmail.com>
Subject: Re: Migration of website to svnpubsub
From: Gert Vanthienen <gert.vanthienen@gmail.com>
To: dev@servicemix.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

L.S.,

> CXF and Camel  (and ActiveMQ) are a bit different in that they still main=
tain their sites and all content in Confluence.   ServiceMix has changed to=
 using a maven site stuff.
>
> HOWEVER, there may even be an easier solution.   If the maven build can b=
e setup to accept and output directory (instead of target/site or whatever)=
, you can have infrastructure setup a buildbot build that will run the buil=
d and automatically handle all the svn stuff.   It would trigger on checkin=
 of the site source, build, publish, etc=85 all automatically.   Developers=
 would never need to "site-deploy" or anything like that.

Yeah, I think it should be possible to set that up as well - we are
using two external tools in the documentation generation process that
might be a problem: Pygments to generate the CSS-markup for the code
snippets and Prince XML to generate the PDF variants for the
documentation.  We would have to get in touch with infra@ to figure
out what's possible - I think the former is already available (think I
have seen it being mentioned on the CMS/svnpubsub discussions before).
 The real issue might be that we have separate builds for the website
and the documentation sections, to allow for version-based
documentation.


> Basically, CXF/Camel kind of "abuse" that by running maven to call a Java=
 program that does the export to the target directory.   Infra then has the=
 script to add/rm/commit/etc=85 the output.  Since CXF/Camel are in conflue=
nce, they don't have the "trigger on checkin" option and instead are timed =
builds.
>
> That said, depending on the amount of content, it might just be better to=
 go with the CMS.   The CMS would allow others to "fork" the site, make cha=
nges, submit diffs, make comments, etc=85 that we wouldn't get from the Mav=
en build.

Personally, I'd rather spend time adding contents to our documentation
base than converting it to the CMS, but I'm open to anything here: if
someone wants to give this option a go or look into it, this is fine
for me too.


Regards,

Gert