Where have you committed the code about confluence -> docbook converter (maven plugin to reuse Mylyn Wikitext) ?
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 Wed, Jun 23, 2010 at 6:43 AM, Guillaume Nodet <[email protected]> wrote: > On Fri, Jun 18, 2010 at 13:53, Guillaume Nodet <[email protected]> wrote: >> FWIW, I'm working on enhancing the confluence -> docbook converter >> maven plugin to reuse Mylyn Wikitext project. This will offer much >> more features that what it provides now, such as links whithin the >> document and much more. > > I've committed the changes i was working on. > >> I've also written a small maven plugin which generate some docbook xml >> based on the console commands, so we can include all the command >> reference as an appendix or something like that. I'll check it in >> asap. > > This one has also been committed at Karaf. > >> >> On Fri, Jun 18, 2010 at 11:48, 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 >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
