I think using confluence instead of docbook brings the nice benefit of making patch way easier. Patches on xml are always difficult because tools have a bad habit of reformating the whole xml which makes diff quite useless. I personnaly would rather use confluence without any editor than docbook with a nice editor, but that's a personal opinion.
On Fri, Jun 18, 2010 at 16:15, Charles Moulliard <[email protected]> wrote: > Hi Gert, > > I have made some tests using wikitext to convert confluence into > docbook. I will send you in a separate email the result (pdf) > including camel bindy page. So you can see the result. Except some > modifications to do in the table, the result seems good for me. If we > work like that we could generate one support documentation using > confluence or docbook files as input entries. > Remark : There is an excellent WYSIWYG editor for docbook doc > (http://www.xmlmind.com/xmleditor/). > > KR, > > Charles Moulliard > > Senior Enterprise Architect (J2EE, .NET, SOA) > Apache Camel - ServiceMix Committer > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Blog : http://cmoulliard.blogspot.com | Twitter : > http://twitter.com/cmoulliard > Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard > > > > On Fri, Jun 18, 2010 at 11:48 AM, Gert Vanthienen > <[email protected]> wrote: >> L.S., >> >> The documentation project is currently set up to use the DocBook >> toolchain to generate the the HTML pages and PDF documents. For >> writing the actual content, there are two options: >> - use the pure DocBook XML syntax >> - use Confluence wiki markup, which will be transformed to DocBook XML >> in the target/docbkx/sources folder to be picked up by the DocBook >> tooling again >> >> We talked about which syntax to use in >> http://servicemix.396122.n5.nabble.com/PROPOSAL-Starting-the-documentation-project-td447701.html#a447701 >> -- personally, I would use the Confluence wiki markup wherever we can >> for most of the text (because it's less verbose, easier to >> write/maintain, ...) but we'll keep the big outline and things like >> tocs, indices, ... in DocBook XML to ensure we can get the most out of >> that toolchain as well. >> >> Regards, >> >> Gert Vanthienen >> ------------------------ >> Open Source SOA: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> >> >> On 18 June 2010 11:10, Charles Moulliard <[email protected]> wrote: >>> Gert, >>> >>> Do you plan to word and build the documentation using docbook ? >>> >>> KR, >>> >>> Charles Moulliard >>> >>> Senior Enterprise Architect (J2EE, .NET, SOA) >>> Apache Camel - ServiceMix Committer >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Blog : http://cmoulliard.blogspot.com | Twitter : >>> http://twitter.com/cmoulliard >>> Linkedin : http://www.linkedin.com/in/charlesmoulliard | Skype: cmoulliard >>> >>> >>> >>> On Fri, Jun 18, 2010 at 10:29 AM, Jean-Baptiste Onofré <[email protected]> >>> wrote: >>>> Hi Gert, >>>> >>>> +1 >>>> >>>> It's a good idea. >>>> >>>> I think that we need to see three big topics in our documentation : >>>> - user guide: people who mainly create the artifacts (SU/SA/OSGi bundles) >>>> - administrator guide: people who are responsible of SMX in production >>>> (installation, monitoring, deployment of artifacts, etc) >>>> - developer guide: people who work around ServiceMix, on bottom of the >>>> artifacts >>>> >>>> Regards >>>> JB >>>> >>>> On Fri 18/06/10 10:12, "Gert Vanthienen" [email protected] wrote: >>>>> L.S., >>>>> >>>>> In the documentation projects' docs/manual directory, we are building >>>>> a ServiceMix users/programmers guide. I would like to add parts for >>>>> all the different technologies we have in ServiceMix in a more or less >>>>> 'natural' order of use (similar to what we have in >>>>> http://servicemix.apache.org/SMX4/technology-selection-guidelin >>>>> es.html >>>> at the moment): >>>>> >>>>> * part 1 : overview and getting started -- there's already have a good >>>>> deal of content for this part that was created by Jean-Baptiste and >>>>> Charles, the technology selection guidelines probably fit into this >>>>> section well as well >>>>> * part 2 : Camel -- about creating, deploying, monitoring, ... Camel >>>>> routes >>>> * part 3 : ActiveMQ >>>>> * part 4 : CXF >>>>> * part 5 : NMR >>>>> * part 6 : JBI -- the goal here is to focus on deployment options, >>>>> packaging, ... - the full reference of endpoints/components will be >>>>> available in a seperate JBI reference manual (in the docs/jbi >>>>> directory) >>>>> >>>>> If this looks OK to people, I'll start moving things a bit, create >>>>> stub pages for the different parts and get started on the Camel >>>>> section myself. >>>>> >>>>> Wdyt? >>>>> >>>>> Gert Vanthienen >>>>> ------------------------ >>>>> Open Source SOA: http://fusesource.com >>>> Blog: http://gertvanthienen.blogspot.com/ >>>>> >>>>> >>>> >>>> >>> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
