On Friday 18 March 2011 10:05:54 AM zoe slattery wrote:
> On 18/03/2011 13:44, Charles Moulliard wrote:
> > Hi,
> > 
> > My question is perhaps stupid but why don't we use wiki/confluence
> > like Apache ServiceMix/Camel/Karaf/ActiveMq projects. I know that
> > confluence is not the most powerful tool to be used but it helps a
> > lot. Additionialy, we use maven plugin to generate Camel manual. This
> > process has been enhanced with Apache Karaf project using
> > scala/scalate to generate the manual in PDF, HTML format. In this
> > case, the pages of the manual are edited manually (outside of the web
> > site) and this process is governed by SVN
> 
> See here: http://www.apache.org/dev/cms.html
> 
> The short summary is that confluence will not be supported and any
> projects using it should be moving to CMS which is actually a lot
> bettter :-)
 
"A lot better" is certainly subjective.   I wouldn't agree with it.  :-)     
The markdown syntax of the CMS certainly is a step backwords compared to the 
Confluence syntax.

What I kind of keep hoping for is that one of the Scalate experts would step 
up and wire Scalate into the CMS (write an extension mapper thing for the cms) 
that would allow using Scalate with the CMS.   Thus, we could retain the use 
of the Confluence syntax (Scalate has a templating thing for that), but still 
be able to use the CMS.


Dan


> 
> > Regards,
> > 
> > Charles
> > 
> > On Fri, Mar 18, 2011 at 2:04 PM, Holly Cummins<[email protected]>  
wrote:
> >> Jeremy wrote:
> >>> It's very easy for committers to make changes using CMS, but for
> >>> contributors (inlcuding those who don't have an ASF id) they have to
> >>> check out the site, configure the build env, build it (instructions on
> >>> our site) and submit a patch. Then the committer applying the patch
> >>> also needs the full site checked out and configured to build. I think
> >>> that process could be improved on, but that would need changes in CMS
> >>> a) to allow anyone to make changes in a sandbox and create a patch for
> >>> a committer b) for a committer to be able to take that patch and apply
> >>> it.
> >>> 
> >>> So I don't think the patch process doesn't work (unless you can
> >>> elaborate), just that it's long winded.
> >> 
> >> Patching documentation is not something I have direct experience of
> >> myself, so I should avoid getting myself in too deep into this
> >> discussion! I was judging by Alasdair and Charles's comments at the end
> >> of
> >> https://issues.apache.org/jira/browse/aries-597, and so Alasdair or
> >> Charles is probably better placed to comment than me.
> >> 
> >> It appears Alasdair tried several times to merge in Charles's patch,
> >> sent it back to Charles to see if Charles could do anything, and then
> >> ended up manually merging in Charles's changes, with the comment "I
> >> guess the diff capability in Apache CMS is broken, or not intended for
> >> creating patches. "
> >> 
> >> If we have to do that every time it won't be a great experience for
> >> either committer or patch-provider. But maybe there's a better way.
> >> 
> >> Holly
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> Unless stated otherwise above:
> >> IBM United Kingdom Limited - Registered in England and Wales with number
> >> 741598.
> >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> >> 3AU

-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com

Reply via email to